腐败 - 如何实现它？ [英] Corruption - how to MAKE it happen?
问题描述
我和一些同事以及我的老板进行了友好的辩论。
我们使用Access 2003作为前端（在工作站上）以及
后端（运行Windows 2000服务器的Dell PowerEdge，SP4）。
我们有大约。 20个用户*在任何时间登录*（超过300
用户ID存在），但我们从未运行指标来查看
平均有多少访问数据库同时发生。
大约每隔几周，数据库就会神秘地变成
损坏。
一件事看起来非常可靠的是，如果我的同事或我在一个表的设计模式中并手动编辑记录而其他人
正在编辑相同的记录前端。
另外，我想如果我异常退出程序（CTRL-
ALT-DEL并在程序加载时终止进程，等），那将是一个非常好的破坏数据库的机会。特别是
（仅限？）如果你在访问记录时杀了它，在它之前
关闭记录集等等。
任何人都可以在这里放光吗？我在整个新闻组中找到了几个参考资料
，甚至是腐败常见问题解答：
http://www.granite.ab.ca/access/corruptmdbs.htm
但是我我真的想知道异常终止是否/应该b / b
这样做。到目前为止，随机测试无法重现所需的损失。我甚至尝试运行代码，在记录操作的中间设置一个断点，然后按CTRL-ALT-DELing进程。
没有损坏。
帮助？
谢谢。
I am in a friendly debate with some co-workers... and my boss.
We use Access 2003 for the frontend (on workstations) as well as for
the backend (on a Dell PowerEdge running Windows 2000 server, SP4).
We have approx. 20 users *logged in* at any one time (over 300
userid''s exist), but we have never run metrics to see how many on
average are accessing the database concurrently.
About once every few weeks, the database mysteriously becomes
corrupted.
One thing that seems pretty reliable is if my co-worker or I are in
design mode of a table and manually edit a record while someone else
is editing the same record via the frontend.
In addition, I thought that if I abnormally exited the program (CTRL-
ALT-DEL and kill the process while the program is loading, etc.), that
there would be a very good chance of corrupting the DB. Especially
(only?) if you killed it while it was accessing a record, before it
closed a recordset, etc.
Can anyone shed any light here? I have found several references
throughout this newsgroup, and even a Corruption FAQ:
http://www.granite.ab.ca/access/corruptmdbs.htm
but I would really like to know if abnormal termination would/should
do it. Random testing so far has been unable to reproduce the desired
corruption. I even tried running the code, setting a breakpoint in
the middle of a record operation, then CTRL-ALT-DELing the process.
No corruption.
Help?
Thanks.
推荐答案
拥有不止一个用户登录到一个整体的Access数据库或者
a前端会大大增加腐败的可能性，但是没有
保证它 - 根据你的描述然而，这似乎不是你的情况。
因为它是一个文件服务器，当与Jet后端一起使用时，所有
处理是在用户的机器上完成的，因此异常终止是在用户的机器上完成的。在
处理中的特定点可能会使内部指针不正确地设置
，因为操作未完成。由于微软没有公布内部的详细信息，以及何时，何地以及为何设置/重置指针，
很难更具体。也就是说，不合适。或异常
终止经常涉及，但它并不总是导致腐败。
由于Access-Jet的运作方式，见上文，即使它们是断断续续的，简短的，也比其他大多数软件更加灵敏。> / b $ b。 >
而且，如果我有一份确保导致损失的情况清单，我不确定我是否认为在<中发布这些情况是合适的br />
公共新闻组。我可能会与微软分享这些内容，希望能找到一个
修复或解决方法，所以很快就会申请。
Larry Linson
Microsoft Access MVP
" Doug" < sp ******* @ gmail.com写信息
新闻：11 ********************** @ y80g2000hsf.googlegr oups.com ...
Having more than a single user logged in to a montolithic Access database or
a front-end significantly increases the chances of corruption, but does not
guarantee it -- based on your description, however, that does not seem to be
your case.
Because it is a file-server, when used with a Jet back-end, all the
processing is done on the user''s machine, thus "abnormal termination" at
particular points in processing may leave internal pointers improperly set
because an operation was not completed. As Microsoft does not publish
details of the internals, and when, where, and why pointers are set/reset,
it''s difficult to be more specific. That is, "ungraceful" or "abnormal"
termination is often involved, but it does not **always** cause corruption.
Because of the way Access-Jet operates, see above, it is far more sensitive
to dropped network connections, even if they are intermittent and brief,
than most other software.
And, well, if I had a list of situations that were guaranteed to cause
corruption, I''m not sure I''d think it appropriate to publish those in a
public newsgroup. I''d probably share them with Microsoft, in hopes that a
fix or workaround could be found, so they would soon not apply.
Larry Linson
Microsoft Access MVP
"Doug" <sp*******@gmail.comwrote in message
news:11**********************@y80g2000hsf.googlegr oups.com...
>我与一些同事和我的老板进行了友好的辩论。
我们使用Access 2003作为前端（在工作站上）以及
后端（在运行Windows 2000服务器的Dell PowerEdge上，SP4）。
我们有约。 20个用户*在任何时间登录*（超过300
用户ID存在），但我们从未运行指标来查看
平均有多少访问数据库同时发生。
大约每隔几周，数据库就会神秘地变成
损坏。
一件事看起来非常可靠的是，如果我的同事或我在一个表的设计模式中并手动编辑记录而其他人
正在编辑相同的记录前端。
另外，我想如果我异常退出程序（CTRL-
ALT-DEL并在程序加载时终止进程，等），那将是一个非常好的破坏数据库的机会。特别是
（仅限？）如果你在访问记录时杀了它，在它之前
关闭记录集等等。
任何人都可以在这里放光吗？我在整个新闻组中找到了几个参考资料
，甚至是腐败常见问题解答：
http://www.granite.ab.ca/access/corruptmdbs.htm
但是我我真的想知道异常终止是否/应该b / b
这样做。到目前为止，随机测试无法重现所需的损失。我甚至尝试运行代码，在记录操作的中间设置一个断点，然后按CTRL-ALT-DELing进程。
没有损坏。
帮助？
谢谢。
>I am in a friendly debate with some co-workers... and my boss.
We use Access 2003 for the frontend (on workstations) as well as for
the backend (on a Dell PowerEdge running Windows 2000 server, SP4).
We have approx. 20 users *logged in* at any one time (over 300
userid''s exist), but we have never run metrics to see how many on
average are accessing the database concurrently.
About once every few weeks, the database mysteriously becomes
corrupted.
One thing that seems pretty reliable is if my co-worker or I are in
design mode of a table and manually edit a record while someone else
is editing the same record via the frontend.
In addition, I thought that if I abnormally exited the program (CTRL-
ALT-DEL and kill the process while the program is loading, etc.), that
there would be a very good chance of corrupting the DB. Especially
(only?) if you killed it while it was accessing a record, before it
closed a recordset, etc.
Can anyone shed any light here? I have found several references
throughout this newsgroup, and even a Corruption FAQ:
http://www.granite.ab.ca/access/corruptmdbs.htm
but I would really like to know if abnormal termination would/should
do it. Random testing so far has been unable to reproduce the desired
corruption. I even tried running the code, setting a breakpoint in
the middle of a record operation, then CTRL-ALT-DELing the process.
No corruption.
Help?
Thanks.
" Doug" ; < sp ******* @ gmail.comwrote：
"Doug" <sp*******@gmail.comwrote:
>看起来非常可靠的一件事是，如果我的同事或我在<表格的设计模式和手动编辑记录，而其他人
正在通过前端编辑相同的记录。
>One thing that seems pretty reliable is if my co-worker or I are in
design mode of a table and manually edit a record while someone else
is editing the same record via the frontend.
我不太清楚如何进入表的设计模式并编辑
记录。你的意思是数据表模式吗？
I''m not quite clear on how you can be in the design mode of a table and edit a
record. Do you mean datasheet mode?
>另外，我想如果我异常退出程序（CTRL-
ALT-DEL并杀死进程）当程序正在加载等）时，那将很有可能破坏数据库。特别是
（仅限？），如果你在访问记录时杀了它，在它关闭记录集之前等等。
>In addition, I thought that if I abnormally exited the program (CTRL-
ALT-DEL and kill the process while the program is loading, etc.), that
there would be a very good chance of corrupting the DB. Especially
(only?) if you killed it while it was accessing a record, before it
closed a recordset, etc.
客户客户端系统上至少有五次电源故障而且没有UPS，当我在现场时，他们有大约15到20个用户。数据库没有损坏。
我很惊讶。
A client has had at least five power failures with no UPSs on the client systems with
about 15 to 20 users while I was on site. There was no corruption of the database.
I was rather surprised.
>但我真的想知道异常终止会不会/应该这样做。到目前为止，随机测试无法重现所需的腐败。我甚至尝试运行代码，在记录操作的中间设置断点，然后按CTRL-ALT-DELing进程。
没有损坏。
>but I would really like to know if abnormal termination would/should
do it. Random testing so far has been unable to reproduce the desired
corruption. I even tried running the code, setting a breakpoint in
the middle of a record operation, then CTRL-ALT-DELing the process.
No corruption.
可能有效的是运行SQL查询，更新几千条记录并突然从系统中断电。
Tony
-
Tony Toews，Microsoft Access MVP
请仅在新闻组中回复，以便其他人可以
阅读整个消息主题。
Microsoft Access Links，Hints，Tips&会计系统
http://www.granite.ab.ca /accsmstr.htm
Per Doug：
Per Doug:
>大约每隔几周一次，数据库神秘地变得腐败了。
>About once every few weeks, the database mysteriously becomes
corrupted.
这就是为什么我尽力避免在
任务关键型应用程序中使用JET后端的一个原因。
我已经做到了......因为用户'坚持了......但在一个案例中我已经有了很多时间后悔关于玩耍。在这种情况下，
损坏的原因似乎与后端所在的文件服务器有关。我们
将.MDB文件移到另一台服务器上，问题就消失了。
是什么原因导致组织非常庞大，非常
严格的变更控制程序到位，让某人获得移动文件的权利需要花费几个月的时间 - 在此期间用户生活
成为由于反复出现的腐败而非常困难。
用户最终支付3百万美元用于重写应用程序（并且，在IT的坚持下，
添加网页访问权限 - 只需要废弃重写并转到另一个外部
供应商再做一遍。
如果他们已经刚刚买了一个SQL Server后端，我没有怀疑他们还在运行那个应用程序。
-
PeteCresswell
This is one reason why I do my best to avoid using a JET back end for a
mission-critical application.
I''ve done it... because the user''s insisted on it... but in one case I''ve had
big time regrets about playing along. In that case, the cause of the
corruptions seemed to be something about the file server the back end was on. We
moved the .MDB file to another server and the problem went away.
What made it so bad was that the organization was very large, with extremely
stringent change control procedures in place and getting somebody who had
permission to move the file took literally months - during which the users lives
became very difficult due to the recurring corruptions.
User wound up paying 3 mil for IT to rewrite the app (and, at IT''s insistence,
add web access) - only to have to scrap the rewrite and go to another outside
vendor to do it all over again.
If they''d just bought into an SQL Server back end in the first place, I have no
doubt they would still be running that application.
--
PeteCresswell
这篇关于腐败 - 如何实现它？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
