是什么原因导致前端为我工作，但是为另一个用户耗尽了堆栈空间 [英] What causes a front end to work for me, but run out of stack space for another user

问题描述

我已将数据库拆分为包含表格的后端，而前端包含其他所有内容。


我已将此数据库上传到共享驱动器，并且应用以下安全设置：

- 禁用文档选项卡

- 禁用访问特殊键

- 禁用导航窗格

- 禁用完整菜单

- 禁用默认快捷菜单


当我尝试运行前端时，无论是从我自己桌面上的副本还是副本在共享驱动器上，它对我来说非常好 - 它会显示我的登录表单，我可以登录并访问其他所有内容。

但是，我在新加坡有一位同事现在正试图访问前端。每次他加载前端（直接从共享驱动器上的副本，或通过将其复制到他的桌面）并尝试登录，整个事情停止响应，并在几分钟后，它最终显示一个消息框说 ;检测到错误：堆栈空间不足。


一旦这个错误发生在我的同事身上，当我尝试相同的前端时，它也适用于我 - 它'''好像有什么事情在他尝试时会发生，这会破坏整个文件。

我注意到的是当它开始没有响应时，在右下角它会显示运行查询。停留在0％的进度条旁边。如果我禁用查询它会被卡住，它会继续，但问题发生在下一个试图运行的查询。

我的同事几个月前打开了这个文件而没有任何问题 - 但这是在数据库被拆分之前，在我禁用上面列出的任何选项之前。


任何人都可以提出任何可能的建议，为什么会发生这种情况，以及我怎么做修理它？我完全不知道为什么会这样，甚至不知道如何调试这个问题！


提前谢谢。


Adam。


更新：因为错误消息导致我的同事通过任务管理器关闭Access，所以它会打开他的连接。一旦这个连接被杀死，前端对我来说绝对没问题 - 所以问题似乎与他有关。

I''ve split a database into a back end containing the tables, and the front end containing everything else.

I''ve uploaded this to a shared drive, and applied the following security settings:
- Disabled Document Tabs
- Disabled Access Special Keys
- Disabled Navigation Pane
- Disabled Full Menus
- Disabled Default Shortcut Menus

When I try running the front end, either from a copy on my own desktop, or the copy on the shared drive, it works absolutely fine for me - it brings up my login form, I can login and access everything else.
However, I have a collegue in Singapore who is now trying to access the front end. Everytime he loads up the front end (either directly from the copy on the shared drive, or by copying it to his desktop) and tries to login, the whole thing stops responding, and after a few minutes it eventually displays a message box saying "Error detected: Out of stack space."

Once this error has happened for my collegue, when I then try the same front end, it happens for me too - it''s as though something happens when he tries it, which corrupts the entire file.
What I''ve noticed is when it starts to not respond, in the bottom right corner it says "Run query" next to a progress bar that is stuck on 0%. If I disable the query it''s getting stuck at, it will proceed, but the problem occurs at the next query that tries to run.
My collegue has opened this same file a few months ago without any problem - however this was before the database was split, and before I disabled any of the options listed above.

Can anyone offer any possible suggestion why this is happening, and how I could fix it? I am completely stumped as to why this is happening and don''t even know how to go about debugging this problem!

Thanks in advance.

Adam.

UPDATE: Because the error message is causing my collegue to close Access via Task Manager, it leaves his connection open. Once this connection is killed, the front end works absolutely fine for me again - so the problem seems to be specifically with him.

推荐答案

亚当，我建议你需要在探讨此问题之前，请先了解更多信息。


为什么不创建调试版本（参见在VBA中进行调试）您的同事的FE在启动代码中有各种 Debug.Print 行说明执行了什么并为每条消息添加时间戳。当您的同事收到错误消息时，他应该进入并复制来自VBA IDE的立即窗格的消息并将其发送给您。我知道，但它可以非常灵活，至少你会在问题中提出一些问题。


此外，BE数据库与每个数据库的关系在哪里网络明智吗？如果您在新加坡的同事通过WAN访问它，那么您总是可以预料到严重的问题。访问始终对网络连接特别敏感。如果会话中的任何Access数据包未能收到，则会话将在没有恢复的情况下死亡，并且通常会发生数据库损坏。 WAN很少能够以与LAN相同的方式保证连续连接。

Adam, I suggest you need to find out some more information before exploring this issue.

Why don''t you create a debug version (See Debugging in VBA) of the FE for your colleague with various Debug.Print lines in the startup code saying what has executed and timestamp each message. When your colleague gets the error message he should go in and copy the messages from the Immediate Pane of the VBA IDE and send them to you. Fiddly I know, but it can be quite flexible and at least you''d have something to ask about in the question.

Also, where is the BE database in relation to each of you network-wise? If your colleague in Singapore is accessing it over a WAN then you can always expect serious problems. Access has always been particularly sensitive to network connections. If any Access packets within a session fail to be received then the session dies without recovery and db corruptions often ensue. WANs are very rarely if ever able to guarantee continuous connection in the same way LANs can.

您能验证用户是否可以访问数据？你能制作一个副本，让他们到任何链接表来证明他们实际上拥有权利并且ODBC正在工作吗？


Jim

Can you verify the user has access to the data? Can you make a copy that lets them get to any linked table to demonstrate they actually have rights and the ODBC is working?

Jim

@ NeoPa：不幸的是，这样的调试可能不会起作用 - 我不认为我的同事对Access的后端方面有足够的了解做这样的事情。


后面最终与我有关的是我认为与我在同一办公室的服务器，位于英国。显然这与新加坡相距甚远，我觉得你可能会发现潜在的问题。如果网络有问题，有没有办法绕过它，后端留在一个位置？


要添加的一件事是我的同事试图访问它通过远程连接和他的标准连接 - 我不知道这是否与绕过网络类型（我猜不是）有关，但两次都有同样的问题。


@Jim：你的意思是做一些像启用导航窗格，并检查他是否可以通过它打开一个表？

@NeoPa: Debugging like that is probably not going to work unfortunately - I don''t think my colleague understands enough about the back end side of Access to do something like that.

The back end in relation to me is on a server that I believe is in the same office as I am, based in the UK. Obviously this is quite a distance from Singapore, and I get the feeling that you might of found the potential problem. If the network is the problem, are there any ways of getting round it, with the back end remaining in a single location?

One thing to add is that my colleague has tried accessing it both via a remote connection and from his standard connection - I don''t know if this has any bearing on bypassing the network type (I''m guessing not) but both times he has the same problem.

@Jim: Do you mean do something like enable the navigation pane, and check if he can open a table via that?

这篇关于是什么原因导致前端为我工作，但是为另一个用户耗尽了堆栈空间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！