在幼儿园里，我要知道我所学的任何东西，不是吗？好的，我过去常常这样想，过去常常是好的共享程序，直到突然使用了Jet复制，我便发现，有时候就你的应用程序性能来说，优秀的共享程序也可能是件糟糕的东西。我这是什么意思？好的，继续读下去……，

情况是很简单明了的——你有一个工作良好的应用程序，你复制它，突然，每一次你做一些简单的事情如打开一个表时，性能则变得莫名其妙了……有时它急速旋转软驱或CDROM驱动器。你准备扯头发着急吧，或（如果你没有头发）准备不复制数据库，除非你可以使它停止！

好了，其实答案很简单……非共享你的驱动器！

是的，对。由于Microsoft Jet的复制跟踪层管理关于副本实际上是不是相同副本的方式，如

\\MACHINE\C$\foo.mdb
\\MACHINE\CROOT\foo.mdb
C:\foo.mdb
H:\foo.mdb (<--mapped to one of the UNC paths above)

它进行某些工作（有些是太多的工作！）来使关于机器共享信息的意义分明，这样，它就知道所有的共享是什么。可惜的是，由于Access 执行*其*某些工作和它如何调用Jet来工作的方式，该“检测”工作通常比你要做的还要多得多。:-(

对用于其他机器的共享连接来说，尤其是，如果其他机器不可用时，那么，它进行的到WNet*功能的内部调用就会存在性能碰撞（perf hit）。对于本地共享，碰撞并不很严重，除非你共享一个CDROM或一个软驱，这种情况，性能碰撞（perf hit）再次值得注意，且实际上很烦人。

那么，你怎样对付这个问题呢？在机器上，只要可能，利用一个使用复制的应用程序，不要均分CDROM驱动器或软驱，尽量避免映射驱动器的网络连接，尤其要减缓连接（使用UNC路径替换）。这将防止你遭受可怕的可能与优秀共享程序有关联的性能碰撞。 :-)

关于本站点的问题，评论和建议，请与 webmaster@trigeminal.com联系。