拆分数据库后的性能令人震惊 [英] Appalling performance after splitting database

问题描述

大家好，在Access 2003中工作（使用Access 2000文件格式）。


我一直在开发一个中等大小的数据库，并且最近获得了写入权限。网络文件夹，它将成为它永久的家。移动到那里后，我去拆分前后端，以便我可以测试链接，分配前端，并开始训练管理员。


但它还没有好了。


以前，加载主窗体最多只需要几秒钟，无论我是从本地硬盘驱动器还是网络上运行它。但是现在任何一种形式都需要10-15秒才能完成，而且有一次我在97秒时将主要形式计时。这时仍然有无数据 - 只有描述和59条记录中的每条记录的一个或两个长整数字段，相关数据非常少。


我认为拆分应该可以帮助它更快地运行？无论如何，这就是我自信地通知客户的......


当我尝试过时，我能想到的任何Access修复都没有做过：


- 紧凑并修复后端和前端

- 编译前端

- 分析后端性能（没有提供建议访问）


我想出的另一个选项是尝试查看是否可以输入表链接的直接网络地址，而不是已映射的驱动器我，如果查找导致某种缓慢 - 但我有疑虑。这个过程需要尝试从IT部门获取信息。


同时，有没有人对我能做什么有其他想法？关于重新连接是否会有所帮助的任何预测？


显然我不能继续开发直到处理完毕，所以现在我要回到预拆分备份。期待尝试任何建议，谢谢！

Hi all, working in Access 2003 (using the Access 2000 file format).

I''ve been developing a moderate-sized database and have recently secured write permission for the network folder that is to be its permanent home. So after moving it there, I went to split the front and back ends so that I could test the links, distribute the front end, and begin training the administrators.

But it hasn''t gone well.

Previously, it only took at most a couple of seconds to load up the main form, whether I was running it off of the local hard drive or the network. But now any of the forms are taking a good 10-15 seconds, and at one point I timed the main one at 97 seconds. This is while there is still no data to speak of--only a description and one or two long integer fields for each of 59 records, with very little related data.

I thought splitting was supposed to help it run faster? That''s what I confidently informed the client, anyway...

None of the Access fixes I can think of have done a thing when I''ve tried them:

- compact and repair back end and front end
- compile front end
- analyze performance of back end (no suggestions provided by Access)

The one remaining option I have come up with is to try seeing if I can type in the direct network address for the table links, rather than the drives that have been mapped for me, in case there is some sort of slowness resulting from the lookup--but I have my doubts. This process will require attempting to get that information out of the IT department.

Meanwhile, does anyone have other ideas of what I can do? And any projections about whether the re-linking will help?

Obviously I can''t keep developing until this is dealt with, so for now I am going back to the pre-split backup. Look forward to trying any suggestions, thanks!

推荐答案

我很惊讶杰里米。我从来没有遇到类似的问题，我仍然主要在2003年和网络上的各种2000数据库工作。是否有可能是一次性命中，随后通过前端打开数据库更加及时？


从驱动器盘符中查找UNC路径（无需IT协助）转到命令提示符窗口并键入 NET USE< Enter> 。

I''m surprised Jeremy. I''ve never had similar issues, and I still work mainly in 2003 and on various 2000 databases across the network. Is it possible that it''s a one-off hit, and that subsequent opens of the database via the front-end are more timely?

To find the UNC path from a drive letter (without requiring IT assistance) go to a command prompt window and type NET USE <Enter>.

谢谢，NeoPa。很高兴至少确认这不是我想要发生的事情。


我已经做了一些挖掘并确信客户使用的是WAN，这可能是根据这个帖子解释症状：
http：// bytes .com / topic / access / answer ... ooo-slooooooow

和本网站的主要贡献者之一：
http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html


我检查了NET USE（非常感谢您的提示），然后在将几个示例表链接到数据库的克隆时能够输入完整的应用程序路径。链接表越多，问题似乎越严重。剩下的一个表格不会查询我链接的表格中的任何信息，它仍会立即打开。所以我认为没有必要继续为所有表格尝试UNC路径。


虽然上面的链接中提出了一些解决方案，但他们需要合作IT，这是一个''异常''足够的要求，我不可能在很短的时间内完成我的工作。这个部门是臭名昭着的。


所有这一切都非常令人讨厌，因为一旦他们开始使用它，数据库将成为关键任务。


我认为目前唯一要做的就是保持它不分裂并在应用程序关闭时进行快速/简单备份，在断开连接损坏的情况下保留5份作为安全网。如果我确定没有打开绑定表单，访问是否足够高兴让我这样做？

Thanks, NeoPa. Good to have confirmation at least that this is Not What''s Supposed To Happen.

I''ve done some digging and learned with certainty that the client uses a WAN, which could account for the symptoms, according to this thread:
http://bytes.com/topic/access/answer...ooo-slooooooow
and this website by one of the thread contributors:
http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html

I checked NET USE (thank you very much for that tip) and was then able to type the full application path in when linking a couple of sample tables to a clone of the database. The more linked tables, the worse the problem seems to get. There is one form remaining that doesn''t query any information from the tables I have linked, and it still opens instantly. So I figure there''s no need to keep trying the UNC path for all tables.

Although there are some solutions suggested in the links above, they would need the co-operation of IT, and it''s an ''abnormal'' enough request that I couldn''t possibly get that working in the very short timescale I have been allowed. The department is notorious.

All of this is really annoying to realise, because the database will be mission critical once they start using it.

I think really the only thing to be done for the moment is keep it unsplit and put in a quick/simple backup on application close that preserves 5 copies as a safety net in case of disconnects that corrupt it. Will Access be happy enough to let me do that if I make sure no bound forms are open?

JeremyI：

我已经做了一些挖掘并确定客户使用WAN

JeremyI:
I''ve done some digging and learned with certainty that the client uses a WAN

我非常好奇关于这个声明。也许我错过了一些东西，但我无法想象这是对你的问题的准确反映。


客户使用网络。该网络是通过WAN还是仅通过LAN进行通信取决于网络本身的配置。客户端不可能（除非可能在非常奇怪和特殊的情况下，不太可能在任何业务环境中发生）决定自己使用WAN。有可能检测到流量是这样的，但这与你发布的内容完全不同（虽然你可能是无意的）。


如果它只是服务器无法通过办公室局域网访问，而不是更简单，更可靠的解决方案是找到所有潜在用户都可以访问局域网的地方。如果那是不可能的，那么你肯定有问题。正如Tony Toews在链接线程中所说，Access根本不能很好地处理WAN。

I''m very curious about this statement. Maybe I''m missing something but I can''t imagine this is an accurate reflection of your issue.

Clients use networking. Whether that network communicates via a WAN or only a LAN is down to the configuration of the network itself. The client cannot possibly (except maybe in really weird and exceptional circumstances, unlikely to occur in any business environment) determine to use the WAN of it''s own accord. It''s possible the traffic is being detected to go that way, but that''s quite different from what you posted (albeit possibly unintentional on your part).

If it simply that the server is not reachable across the office LAN, than a simpler, more reliable, solution would be to find somewhere that is LAN-accessible to all your potential users. If that''s not possible, then you certainly have a problem. As Tony Toews said in the linked thread, Access doesn''t handle WANs very well at all.

这篇关于拆分数据库后的性能令人震惊的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！