可扩展的 MS Access ASP.NET 应用程序
我受到以下限制，没有办法解决：
- 只读数据：Microsoft Access
- JET 4.0 OLDB
- ASP.NET 2.0
- 共享主机，几乎没有控制。
- OR Mapper - LLBL Gen Pro
该应用程序是一个只读工具，可以读取 APP_Data 文件夹中的大量 Microsoft Access 数据库。大部分情况下工作正常。
在负载下，它开始无法访问 Access MDB。
访问 Access MDB 以限制访问它们时出现的错误的最佳策略是什么？现在我尝试，然后 Thread.Sleep(500) 出现错误，然后重试。
I am constrained by the following, no way around it:
- Read-Only Data: Microsoft Access
- JET 4.0 OLDB
- ASP.NET 2.0
- Shared Host, very little control.
- OR Mapper - LLBL Gen Pro
The app is a read-only tool that reads a lot of Microsoft Access Databases in the APP_Data folder. Works fine mostly.
Under load it starts failing accessing the Access MDBs.
What is the best strategy for accessing the Access MDBs to limit errors in accessing them? Right now I try, then Thread.Sleep(500) on an error then try again.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为在访问 Access 数据库时可能有一些方法可以修改隔离/并发/锁定选项，以消除管理锁的开销。也许尝试“Mode=Share Deny None;”在连接字符串中。如果您随时以任何方式修改数据，我不会使用它，因为它几乎抛弃了您通过数据库获得的所有隔离/并发管理。使用风险自负。
I think there may be ways to modify the isolation/concurrency/locking options when accessing the Access databases to eliminate overhead of managing locks. Perhaps try "Mode=Share Deny None;" in the connection string. I would not use this if you are modifying data in any way at anytime though as it's pretty much throwing out all the isolation/concurrency management that you get with a database. Use at your own risk.
数据更改的频率如何？如果它是只读的，您可以将数据从数据库加载到缓存中并从那里读取数据，而不是直接从数据库中读取吗？
得到什么样的具体错误。我认为它们是连接错误？
How frequently does the data change? If it's read-only can you load the data from the databases into cache and read it from there instead of directly from the databases?
What kind of specific errors getting. I assume they are connection errors?
这是一个可怕的解决方案，但如果您真的“迷失在只有这些工具的荒岛上”并且访问数据库是完全只读的，那么为每个数据库创建多个副本，并只允许一定数量的连接到任何数据库一次。例如，如果您有 2 个访问数据库 MdbAA 和 MdbBB，则创建如下副本：
然后当有 MdbAA 请求到来时，查看当前有多少请求正在访问 MdbAA01，如果超过阈值，则尝试 MdbAA02，等等。对 MdbBB 文件的任何请求执行相同的操作。
就像我说的，这是一个非常糟糕的解决方案，但如果你真的别无选择，那么它可能对你有用。但实际上，听起来应用程序已经无法满足 Access（和共享主机）的需求，因此是时候升级架构了。
This is a horrible solution but if you truly are "lost on a desert island with only these tools" and the access databases are completely read-only, then create multiple copies of each of them and allow only a certain number of connection into any of them at a time. For example, if you have 2 access databases, MdbAA and MdbBB then create copies like:
Then when a request comes for MdbAA, see how many requests are currently accessing MdbAA01, if over the threshold, then try MdbAA02, etc. Do the same for any requests to the MdbBB file.
Like I said this is very bad solution but if you truly have no choice then it might work for you. But realistically it sounds like the app has outgrown Access (and the shared host) so it is time to upgrade the architecture.
花点钱买一些sql存储。您花了多少时间为损坏的发声系统安装拐杖？
如果这个项目值得做，那么就值得投入一些现金。
如果企业试图强迫您走这条路，请解释为什么您的选择不可行。如果你一开始就建议了这个选项，那就种植一对并解释为什么你错了，但这就是你可以解决它的方法。
抱歉，如果这听起来很轻率。
Spend a bit of money and get some sql storage. How much time have you spent working on fitting a crutch to a broken sounding system?
If the project is worth doing then it's worth investing some cold hard cash.
If a business is trying to force you down this route, explain why the option you have is not viable. If you suggested the option in the first place, grow a pair and explain why you were wrong, but this is how you can fix it.
Sorry if that comes off as flippant.