我有一个相当大的Access数据库，我正在将其带入21世纪。后端已经转换为SQL Server而不是MDB，我正在考虑如何处理前端，它也在MDB中。我对用户级安全性非常满意，并广泛使用它来管理数据和前端元素的权限。这是我第一次使用ACE/Accdb进行开发，由于它不支持用户级别的安全性，保护表单、查询、报告等的最佳方法是什么？除了编译的前端之外，还有什么吗？
作为一般规则，用户级安全性(ULS(用于确定什么用户可以打开什么表单或什么报告。然而，ULS并不是真正为了"；锁定"；应用程序。这是两个截然不同的目标。现在公平地说，ULS可以帮助锁定事物，但它更倾向于控制用户可以打开或使用应用程序的哪些部分。
在大多数情况下，ULS不会说锁定使用Access UI位和部分。因此，您的应用程序将"；工作；或"；seek"；以隐藏内置Access部件。事实上，这就是编译后的accDB可以提供巨大帮助的地方。(因为编译后的应用程序剥离了源代码，并且还禁用了在设计模式下打开表单/报告和代码的功能。
accDE的另一大优势是什么？好吧，任何未处理的代码错误都不会重新设置局部或全局变量。(因此，您可以获得相当不错的可靠性提高(。编译后的accDE的另一个优点当然是使用免费运行时。这意味着工作站和用户不需要包含Access的付费办公副本。
因此，运行时+编译的accDE有很多好处。(隐藏和锁定Access UI就是这样一个好处(。事实上，作为运行时运行意味着不能使用内置功能区和菜单。如前所述，没有源代码，也没有针对代码或表单/报告的设计能力，这些都会将事情锁定。
因此，以上相当多地意味着ULS是"；更多"；旨在控制谁可以使用应用程序的哪些部分，而不是在更改或修改应用程序方面锁定用户的部分(正如我所说的，这是两个不同的目标(。
因此，在没有任何ULS安全性的情况下，您可以很好地将应用程序部分锁定为像滚筒一样紧密。
然而，ULS在锁定变化和窥探应用程序方面的损失并不是什么大不了的事吗？在控制系统中，谁能在应用程序中做什么，这无疑是一个巨大的损失。既然你没有ULS，那么你就不能使用ULS来控制谁可以做什么，也不能阻止用户做设计模式等事情。所以，这在很大程度上表明，你需要编写代码来阻止一些用户打开表单，你必须为此编写代码。
我当然会遵循用户的经典模型，然后这些用户属于特定的组。正如您所知，如果您在Access中纠正了这一点，那么您可以将FE(前端应用程序部件(的副本带离现场。他们可以在现场更改哪个用户属于哪个安全组。只要他们从未将用户分配给给定的对象(表单/报告等(，那么你就可以更新+部署你的软件的新版本和所有的安全内容，甚至可以将一些用户添加到"；销售组；将继续工作-即使您更新并部署了新的FE。但是，当你把用户分配给任何其他的东西，然后是一个安全组时，整个过程就会崩溃。
已经说过了吗？你必须自己滚。您可以创建一个返回安全信息的SINGLE函数。然后，您可以在打开(而不是加载(时使用这些表单。如果您将cancel设置为true，那么有问题的表单将不会加载也不会显示。因此，您可以在打开事件的表单(或报告(中重新拟合基于此单个函数的安全模型。在大多数情况下，该事件中几乎没有现有代码(打开事件不允许修改表单上的绑定控件-您必须等待并将此类代码放入加载事件中。
所以，你必须自己滚。而且由于你在VBA代码中不能真正"；防止"；用户在设计模式下打开表单？那么，如果你至少想要"；一些"；合理的安全级别。
根据我的经验，MS Access"安全性"；是海市蜃楼。使用Windows安全性并使用几个不同的编译前端要好得多，每个前端都受到保护。
@June7是对的，这不是一个适合SO的问题。