在这里抓住吸管...我使用几个2003风格的Access数据库（.MDB）使用VB6桌面系统。最近，我将第一个函数从VB6更改为VB.NET，仍使用Access数据库。这不仅仅是转换，而是具有附加功能的重写。它仍然是相当简单的功能，具有低容量数据库。我们拥有1400名客户，小型企业拥有不同的机器质量。大多数客户对新屏幕和功能感到满意。这些客户中很少有人经历过加载数据网格视图的极端缓慢。客户服务部门告诉我们：1）机器至少有1 GB的RAM，2）重启始终可以解决问题。
我写了一个应用程序来严重减慢我的机器速度，它对我来说运行得比对少数客户更好。此外，我的Access数据库从未被此应用程序破坏。
有什么建议吗？
谢谢！
答案 0 :(得分：2)
我们有类似的经历，大多数情况都是由防病毒引起的。他们经常检查文件（有些文件会对文件进行任何访问）。
答案 1 :(得分：2)
更新访问数据库时重新启动可能会将其删除。
您需要更多信息，以便更好地了解正在发生的事情。他们需要在遇到问题的工作站上为您收集一些信息。使用任务管理器，您可以获得以下信息：
也可以在XP和Vista上使用命令行工具“SYSTEMINFO”来获取Total和Available内存。如果你的可用性很少而且在XP上，如果你的Total committed大于你的Total Physical，那么你最有可能交换，内存不足（或内存泄漏）导致你的速度减慢。
底线是您需要更多信息。它可能是工作站上的另一个应用程序导致问题。我们遇到的情况是Notes 5.0出现问题，如果大多数窗口被另一个窗口覆盖，并且您收到一封新邮件，则Notes上的cpu利用率达到100％。这导致应用程序运行缓慢，除非您在工作站上查看任务监视器，否则您永远不会猜到它是导致问题的Notes。问题总是在一个不同的程序（前台的程序）中调用。 Access也可以在不同模式下使用100％cpu，即使它似乎没有做任何事情。
收集尽可能多的信息。您可能希望编写一个vbscript或程序，它将为您收集一些信息，以便任何遇到问题的人都可以运行它以在重新启动之前收集信息。
执行以下操作的批处理文件将为您提供相当多的信息：
@echo off
SystemInfo >c:\systeminfo.log
tasklist /v >>c:\systeminfo.log
答案 2 :(得分：0)
不，VB.Net适用于Access。共享环境将无法访问。
由于重新启动解决了问题，我会检查您是否正确关闭了连接。
答案 3 :(得分：-1)
听起来像是一个很大的内存泄漏给我。
有些客户会让您的应用程序运行的时间比其他客户长，并且会受到更大的打击。
在存在多个并发用户的情况下使用Access不可避免地会导致痛苦。