访问 2003 MDB 属性
对于 Access 2003 MDB,是否存在我们可以设置的固有 MDB 属性来禁止或阻止对象导出?换句话说,假设 MDB“A”和“B”。如果我在“B”中并尝试从“A”导入对象(即文件|获取外部数据|导入),我们希望它失败,因为“A”设置了一些属性来锁定其导出对象的能力。
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 some property that locks out its capability to export objects.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在“让诚实的人保持诚实”的标题下,有一个对我有用的简单方法...
“独占”打开后端 MDB 数据库并在其上设置密码。 (不过,正常打开模式将被共享。)随后在前端,必须重新链接来自密码数据库的链接表。为此,Access 需要密码。这些表现在完全可供前端使用。
现在,当我们对已设置密码的数据库执行任何操作时,无论是简单地打开它、从中导入对象还是链接到其中的表,都需要密码。这样的“封锁”足以满足我的情况的要求。
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:
The code to remove the table after it has been used:
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.