Access 2003 MDB properties

With an Access 2003 MDB, is there an inherent MDB property we can set that disallows or blocks object exports? In other words, assume MDBs "A" and "B". If I'm in "B" and try to import objects from "A" (i.e. File | Get External Data | Import), we want it to fail because "A" has set开发者_如何学Python some property that locks out its capability to export objects.

---

Under the heading of 'keeping honest people honest', a simple approach that will work for me...

Open the back-end MDB database 'exclusive' and put a password on it. (Normal open mode will be shared, though.) Subsequently in the front-end, the linked tables from the passworded database must be relinked. In doing so, Access requires the password. The tables are now fully available to the front-end.

Now, when we do anything with the now-passworded database, whether to simply open it, import an object from it or link to a table in it, the password is required. Such a 'blockade' is sufficient for the requirement in my case.

---

Just been having a very similar problem to this. In my case I want to keep the backend password from the users because there is a very small amount of sensitive data in there (and I don't want them messing the other stuff up too easily).

One table in particular I don't want them to have any access to, or at least to minimise the chances of them getting read/write access to this table.

Fortunately, this table is only needed for a short time, so when I need it I use a bit of code to add a link to the table in the back-end database, use the table, then remove the link after it is done.

The code to add the table:

Dim db As Database, tbl As TableDef
Set tbl = New TableDef
With tbl
    tbl.Name = "SecretTable"
    tbl.SourceTableName = "SecretTable"
    tbl.Connect = "MS Access;PWD=BackendPassword;DATABASE=c:\location of database\Backend.mdb"
End With
Call db.TableDefs.Append(tbl)

The code to remove the table after it has been used:

Dim db As Database
Set db = CurrentDb
Call db.TableDefs.Delete("SecretTable")

This works in my situation because the table is only being used briefly. If it were a table being used constantly, clever users could probably get around it.