Custom table property to prevent overwrite?

[deko]

Is there a way to set a custom property on Access tables and/or queries to
prevent them from being overwritten by import wizards? Any Access database
can be easily destroyed if a user mistakenly imports an object (or Excel
spreadsheet) with the same name as an existing table or query.

Import wizard: "Overwrite existing table/query?"

User: yes

Import wizard: overwrites key table or query

User: whoops... I destroyed the database

[Tom van Stiphout]

On Tue, 20 Sep 2005 18:54:03 -0700, "deko" <de**@nospam.com> wrote:

No.
Good backups, and plenty of tar and feathers, should take care of this
issue.
If you want to go to extremes, perhaps there is a way Access security
can prevent some from making inadvertant changes.

-Tom.

Is there a way to set a custom property on Access tables and/or queries to
prevent them from being overwritten by import wizards? Any Access database
can be easily destroyed if a user mistakenly imports an object (or Excel
spreadsheet) with the same name as an existing table or query.

Import wizard: "Overwrite existing table/query?"

User: yes

Import wizard: overwrites key table or query

User: whoops... I destroyed the database

[Sky]

In my experience, the Access import tool does not overwrite existing objects
and instead adds a unique suffix to avoid conflicts.

For example, if you have a table X, and then import an external table also
called X, then the imported version is renamed to X1, and the original X is
not disturbed.

Now exporting is a different matter, in that case Access prompts for
overwriting.

- Steve

"deko" <de**@nospam.com> wrote in message
news:WM********************@comcast.com...

Is there a way to set a custom property on Access tables and/or queries to
prevent them from being overwritten by import wizards? Any Access database can be easily destroyed if a user mistakenly imports an object (or Excel
spreadsheet) with the same name as an existing table or query.

Import wizard: "Overwrite existing table/query?"

User: yes

Import wizard: overwrites key table or query

User: whoops... I destroyed the database

[deko]

> In my experience, the Access import tool does not overwrite existing

objects
and instead adds a unique suffix to avoid conflicts.

For example, if you have a table X, and then import an external table also
called X, then the imported version is renamed to X1, and the original X
is
not disturbed.

Try it with the Import Spreadsheet Wizard

[deko]

> No.

Good backups, and plenty of tar and feathers, should take care of this
issue.

I go through all kinds of trouble to disable shift bypass, hide menubars,
etc, and the Access team lets users overwrite any internal table or query
with nothing but an "are you sure?" ! ! ... they're the ones who should get
the tar and feathers

That import spreadsheet wizard is helpful, but dangerous.

[david epsom dot com dot au]

Create a new Workgroup File.

Create a new user in the new workgroup file.

Use the new workgroup file and user.

Create a new table in the target database.

Remove the "alter design" permission for the Admin user.

Discard the new workgroup file if you like.
Use the original workgroup file.

Now "Admin" is not the owner of the table, and is not a member
of the Admins Group that created the table, and does not have
"alter design" permission on the table,

and can not delete the table.

To delete or alter the table, you will need to use your special workgroup
file.

(david)
"deko" <de**@nospam.com> wrote in message
news:WM********************@comcast.com...

Is there a way to set a custom property on Access tables and/or queries to
prevent them from being overwritten by import wizards? Any Access
database can be easily destroyed if a user mistakenly imports an object
(or Excel spreadsheet) with the same name as an existing table or query.

Import wizard: "Overwrite existing table/query?"

User: yes

Import wizard: overwrites key table or query

User: whoops... I destroyed the database

[deko]

> Create a new Workgroup File.

Create a new user in the new workgroup file.

Use the new workgroup file and user.

Create a new table in the target database.

Remove the "alter design" permission for the Admin user.

Discard the new workgroup file if you like.
Use the original workgroup file.

Now "Admin" is not the owner of the table, and is not a member
of the Admins Group that created the table, and does not have
"alter design" permission on the table,

and can not delete the table.

To delete or alter the table, you will need to use your special workgroup
file.

Sounds interesting. I will do some testing with this. Thanks for the tip.