我有一个商业案例，我正在开发一个简单的搜索UI，我想将它链接到我们的SQL Server，因为我测试时性能非常快。我的计划是创建一些链接表，并为每个链接表（不同的数据集）创建一个整洁的搜索表单。
更新，这是对我的计划的更好描述
我有一个用户ID /密码，我想在4个链接的SQL表的每个ODBC连接中使用它（它被认为是我公司的APP ID，PW永远不会改变）。将有4个表单链接到每个表，每个用户将拥有自己的accde数据库，其中包含一个启动文件，该文件将副本放在用户配置文件驱动器上并从那里打开。这允许每个用户拥有自己的accde文件副本，并且每个人只有一个＆＃34; launch＆＃34;文件。
此搜索用户界面将拥有超过2000名用户，他们知道在任何给定时间实际执行搜索的人数。安全性不是问题，因为它是由我们的IT区域管理的内部SQL Server上的数据库。最终用户都是内部员工。
只使用一个ID可能会锁定我的APP ID并导致重大问题吗？
如果每个用户都有自己的accde文件，MS Acess会不会成为主要阻塞点？
谢谢你，对不起，这个问题的第一个版本并非100％明确，谢谢！
答案 0 :(得分：0)
所以，我想我会回过头来发布我所做的事情。虽然在访问前端的共享位置提供带有文件DSN的单一应用程序ID，但它最终不是最稳定的解决方案。
由于我处于大型企业环境中，因此我的选择非常有限。也就是说，我能够将一个只读角色添加到我管理的数据库中，并获得一个＆＃34; Active Directory组＆＃34;我有所需的会员资格（作为奖励，会员资格在公司层面管理！）我将AD组添加到只读角色。
然后我使用Windows身份验证安全性创建了一个文件DSN，将其放在共享文件夹位置（我还将相同的AD组添加到该文件夹上的只读角色）并通过电子邮件发送出一个简单批处理文件启动器的快捷方式将ACCDE数据库复制到用户配置文件驱动器。
accde包含最终用户所需的所有必要的搜索表单，逻辑和链接表。我甚至建立了一个后门，通过一个简单的文件重命名崩溃最终用户（带警告）。 100名测试组的前端运行速度惊人，并且下周将推出500个。
中提琴。希望这有助于某些人尝试做类似的事情。