终端服务器上的磁盘或网络错误 [英] Disk or Network error on Terminal Server
问题描述
在终端
服务器环境中对此重复出现的磁盘或网络错误的异常旋转。 Access 2000，终端服务器2000，文件服务器是
windows 2000.所有用户都有一个单独的前端数据库副本，
每个人都通过一个访问后端数据库网络共享。前言，
非终端服务器用户（4或5在办公室）从来没有这个问题。
有两个终端服务器运行win 2000，基本上都是
相同。此错误会影响这两个用户。问题是间歇性的，并且没有针对特定用户或后端dbs。
一周几次，各种用户都会在访问中提取一个表单，并且
a组合或子表单将为空。使用错误捕获，或者如果记录源实际上基于受影响的后端db
，则表示用户将收到DISK OR NETWORK ERROR。让
用户关闭数据库并重新打开，甚至拉动
数据库的新副本，在大多数情况下并不能解决问题。让用户
退出终端服务器并重新登录somtimes工作，有时候
不行。很难确定问题的真正含义。
这里是踢球者：如果用户收到错误，则打开Windows
资源管理器，导航到db文件，右键单击.mdb文件，然后
选择PROPERTIES，通常暂停1秒，数据库的属性将打开，现在用户的数据库访问正常。
他们可以立即刷新或关闭/重新打开表单，数据
显示正确。这种情况每次都有效。
我真的想弄明白问题是什么，但是我已经卡住了b $ b。我已经验证所有jetdb版本在所有系统（TS和工作站）上都是相同的。当出现此问题时，
用户与同一共享
驱动器中其他dbs的连接（读/写等）不受影响。
An unusual spin to this recurring disk or network error in a Terminal
Server environment. Access 2000, Terminal Server 2000, file server is
windows 2000. All users have a separate copy of the front end db,
everyone accesses the back-end db via a network share. To preface,
non Terminal Server users (4 or 5 in office) never have this problem.
There are two Terminal Servers running win 2000, both basically
identical. This error affects users on both of them. Problem is
intermittent, and does not target specific users or back-end dbs.
Several times a week, various users will pull up a form in access, and
a combo or subform will be blank. With error trapping, or if pulling
up a form where the recordsource is actually based on the backend db
affected, the user will receive the DISK OR NETWORK ERROR. Having the
user close the database and re-open, even pulling a new copy of the
database, in most cases does not alleviate the problem. Having users
logout of Terminal Server and log back in somtimes works, sometimes
not. Hard to nail down what the problem is really tied to.
Here''s the kicker: If the user receives the error, then opens Windows
Explorer, navigates to the db file, right-clicks the .mdb file and
selects PROPERTIES, there is usually a 1 second pause, the properties
windows for the db opens, and the user''s database access is now ok.
They can immediately refresh or close/re-open the form, and the data
shows correctly. This works EVERY time.
I would really like to figure out what the problem could be, but i''m
stuck. I have verified that all jetdb versions are the same across
all systems (TS and workstations). When this problem occurrs, the
user''s connection (read/write etc) to other dbs in the same shared
drive are not affected.
推荐答案
< ga ********** @ gmail.comwrote in message
新闻：3c ********************************** @ i29g2000 prf.googlegroups.com ...
<ga**********@gmail.comwrote in message
news:3c**********************************@i29g2000 prf.googlegroups.com...
在终端
服务器环境中对此重复出现的磁盘或网络错误的异常旋转。 Access 2000，终端服务器2000，文件服务器是
windows 2000.所有用户都有一个单独的前端数据库副本，
每个人都通过一个访问后端数据库网络共享。前言，
非终端服务器用户（4或5在办公室）从来没有这个问题。
有两个终端服务器运行win 2000，基本上都是
相同。此错误会影响这两个用户。问题是间歇性的，并且没有针对特定用户或后端dbs。
一周几次，各种用户都会在访问中提取一个表单，并且
a组合或子表单将为空。使用错误捕获，或者如果记录源实际上基于受影响的后端db
，则表示用户将收到DISK OR NETWORK ERROR。让
用户关闭数据库并重新打开，甚至拉动
数据库的新副本，在大多数情况下并不能解决问题。让用户
退出终端服务器并重新登录somtimes工作，有时候
不行。很难确定问题的真正含义。
这里是踢球者：如果用户收到错误，则打开Windows
资源管理器，导航到db文件，右键单击.mdb文件，然后
选择PROPERTIES，通常暂停1秒，数据库的属性将打开，现在用户的数据库访问正常。
他们可以立即刷新或关闭/重新打开表单，数据
显示正确。这种情况每次都有效。
我真的想弄明白问题是什么，但是我已经卡住了b $ b。我已经验证所有jetdb版本在所有系统（TS和工作站）上都是相同的。当出现此问题时，
用户与同一共享
驱动器中其他dbs的连接（读/写等）不受影响。
An unusual spin to this recurring disk or network error in a Terminal
Server environment. Access 2000, Terminal Server 2000, file server is
windows 2000. All users have a separate copy of the front end db,
everyone accesses the back-end db via a network share. To preface,
non Terminal Server users (4 or 5 in office) never have this problem.
There are two Terminal Servers running win 2000, both basically
identical. This error affects users on both of them. Problem is
intermittent, and does not target specific users or back-end dbs.
Several times a week, various users will pull up a form in access, and
a combo or subform will be blank. With error trapping, or if pulling
up a form where the recordsource is actually based on the backend db
affected, the user will receive the DISK OR NETWORK ERROR. Having the
user close the database and re-open, even pulling a new copy of the
database, in most cases does not alleviate the problem. Having users
logout of Terminal Server and log back in somtimes works, sometimes
not. Hard to nail down what the problem is really tied to.
Here''s the kicker: If the user receives the error, then opens Windows
Explorer, navigates to the db file, right-clicks the .mdb file and
selects PROPERTIES, there is usually a 1 second pause, the properties
windows for the db opens, and the user''s database access is now ok.
They can immediately refresh or close/re-open the form, and the data
shows correctly. This works EVERY time.
I would really like to figure out what the problem could be, but i''m
stuck. I have verified that all jetdb versions are the same across
all systems (TS and workstations). When this problem occurrs, the
user''s connection (read/write etc) to other dbs in the same shared
drive are not affected.
看看MicroSoft知识库文章889588.
你是否在前端和后端之间有持久连接-end
数据库？
Take a look at MicroSoft KB article 889588.
Do you have a persistent connection between the front-end and back-end
database?
2月18日，12：58 * pm，paii，Ron < n ... @ no.comwrote：
On Feb 18, 12:58*pm, "paii, Ron" <n...@no.comwrote:
< gary0gilb ... @ gmail.comwrote in message
新闻：3c ********************************** @ i29g2000 prf.googlegroups.com ...
<gary0gilb...@gmail.comwrote in message
news:3c**********************************@i29g2000 prf.googlegroups.com...
在终端
服务器环境中对此重复出现的磁盘或网络错误进行异常调整。 * Access 2000，终端服务器2000，文件服务器是
windows 2000. *所有用户都有一个单独的前端数据库副本，
每个人都访问后端数据库通过网络共享。 *前言，
非终端服务器用户（办公室中有4个或5个）从来没有这个问题。
有两个终端服务器运行win 2000，两者基本上都是
相同。 *此错误会影响两者的用户。 *问题是
间歇性，并且不针对特定用户或后端dbs。
一周几次，各种用户会在访问中提取一个表单，并且
a组合或子表格将为空白。 *使用错误捕获，或者如果将记录源实际上基于受影响的后端db
的表单拉出
，则用户将收到DISK OR NETWORK ERROR。 *让
用户关闭数据库并重新打开，甚至拉动
数据库的新副本，在大多数情况下并不能解决问题。 *让用户
退出终端服务器并重新登录somtimes工作，有时
不行。 *很难确定问题的真正含义。
An unusual spin to this recurring disk or network error in a Terminal
Server environment. *Access 2000, Terminal Server 2000, file server is
windows 2000. *All users have a separate copy of the front end db,
everyone accesses the back-end db via a network share. *To preface,
non Terminal Server users (4 or 5 in office) never have this problem.
There are two Terminal Servers running win 2000, both basically
identical. *This error affects users on both of them. *Problem is
intermittent, and does not target specific users or back-end dbs.
Several times a week, various users will pull up a form in access, and
a combo or subform will be blank. *With error trapping, or if pulling
up a form where the recordsource is actually based on the backend db
affected, the user will receive the DISK OR NETWORK ERROR. *Having the
user close the database and re-open, even pulling a new copy of the
database, in most cases does not alleviate the problem. *Having users
logout of Terminal Server and log back in somtimes works, sometimes
not. *Hard to nail down what the problem is really tied to.
这里是踢球者：*如果用户收到错误，则打开Windows
资源管理器，导航到在db文件中，右键单击.mdb文件并且
选择PROPERTIES，通常会有1秒的暂停，数据库的属性为/ b
打开，用户现在可以使用数据库访问了。
他们可以立即刷新或关闭/重新打开表单，数据
显示正确。 *这适用于每一次。
Here''s the kicker: *If the user receives the error, then opens Windows
Explorer, navigates to the db file, right-clicks the .mdb file and
selects PROPERTIES, there is usually a 1 second pause, the properties
windows for the db opens, and the user''s database access is now ok.
They can immediately refresh or close/re-open the form, and the data
shows correctly. *This works EVERY time.
我真的想弄明白问题是什么，但是我已经卡住了b $ b。 *我已经验证所有jetdb版本在所有系统（TS和工作站）上都是相同的。 *当出现此问题时，
用户与同一共享
驱动器中其他dbs的连接（读/写等）不受影响。
I would really like to figure out what the problem could be, but i''m
stuck. *I have verified that all jetdb versions are the same across
all systems (TS and workstations). *When this problem occurrs, the
user''s connection (read/write etc) to other dbs in the same shared
drive are not affected.
看看MicroSoft知识库文章889588.
你是否在前端和后端之间有持久连接-end
数据库？ - 隐藏引用文字 -
- 显示引用文字 -
Take a look at MicroSoft KB article 889588.
Do you have a persistent connection between the front-end and back-end
database?- Hide quoted text -
- Show quoted text -
是的，在各种（10个以上）后端数据库中（所有这些都在相同的
网络地图驱动器上），数据的持久连接打开到5个主要后端的
。并且它总是这5个主要后端之一
有问题。
查看文章，我们的文件/路径命名约定符合（所以
可能意味着我不必担心禁用自动短的
文件名生成），服务器上的文件系统是NTFS，而且
db登录界面创建与数据源的持久连接。
我们所有的非终端服务器客户端都在Windows XP Professional上。
计算机，但是像TS用户一样工作，分开单独的
前端。我之前已经检查过这些工作站上的oplock，但是
将再次dblcheck以确保没有任何问题。我将不得不进一步检查一些服务器注册表设置。
Yes, out of the various (10+) backend databases (all on the same
network map drive), there are persistent connections on data open to
the 5 main backends. And it''s always one of these 5 main backends
that has the problem.
Looking at the article, our file/path naming conventions conform (so
probably means i don''t have to worry about the Disable automatic short
file name generation), the file system on the server is NTFS, and the
db login screen creates a persistent connection to the datasources.
All of our non-terminal server clients are on Windows XP Professional
computers, but they work just like the TS users with a split separate
front end. I''ve checked the oplocks on these workstations before, but
will dblcheck again to make sure nothing is amiss. I''ll have to do a
little further checking into some of the server registry settings.
ga ********** @ gmail.com 写道：
ga**********@gmail.com wrote:
>终端
服务器环境中此重复出现的磁盘或网络错误的异常旋转。
>An unusual spin to this recurring disk or network error in a Terminal
Server environment.
我一直在思考这个问题，看看是否有任何想法。而你
确实有一个非常有趣的问题。
它不是服务器上的网卡，除非服务器有多个网卡
，其中一张卡位于只有TS系统使用的网络交换机上。
其他用户通过另一块网卡上的网络交换机进入。
并且两个TS有同样的问题？我在想这就是TS系统所在的网络交换机
。文件服务器是否连接在同一网络上？
切换？如果TS系统和文件服务器在不同的交换机上，我会考虑两个网络交换机之间的电缆。
现在你的IT部门可能会极力反对我的建议。
毕竟它几乎肯定只是你的Access应用程序显示出任何问题。
因此问题是你的应用程序或Access。或者这样他们的想法。而我/ b $ b可以欣赏他们来自哪里。
然而，Access是煤矿中众所周知的金丝雀。它对间歇性网络问题非常敏感。
IT部门可以查看这些交换机上的任何日志吗？他们可以查看
还有什么吗？
I''ve been ruminating on this one for a bit to see if anything comes to mind. And you
do have a very interesting problem.
It''s not a network card on the server unless the server has multiple network cards
with one of those cards being on a network switch which only the TS systems use.
And the other users are coming in via a network switch on another network card.
And for two TS to have the same problem? I''m thinking that it''s the network switch
on which the TS systems reside. Does the file server attached on the same network
switch? If the TS systems and the file server are on different switches I''d be
thinking about the cable(s) between the two network switches.
Now your IT department are likely going to strenuously disgree with my suggestion.
After all it''s almost certainly only your Access app which is showing any problems.
Therefore the problem is your app or Access.; Or so will go their thinking. And I
can appreciate where they are coming from.
However Access is the proverbial canary in a coal mine. It is very sensitive to
intermittent network issues.
Can the IT department view any logs on those switches? Is there anything else on
their that they can review?
>这里是踢球者：如果用户收到错误，然后打开Windows资源管理器，导航到db文件，右键单击.mdb文件并选择属性，通常暂停1秒，数据库的属性窗口打开，用户的数据库访问现在可以。
他们可以立即刷新或关闭/重新打开表单，并且数据正确显示。这适用于每一次。
>Here''s the kicker: If the user receives the error, then opens Windows
Explorer, navigates to the db file, right-clicks the .mdb file and
selects PROPERTIES, there is usually a 1 second pause, the properties
windows for the db opens, and the user''s database access is now ok.
They can immediately refresh or close/re-open the form, and the data
shows correctly. This works EVERY time.
现在不是很有趣。但是，我永远不会*记得任何一个带有可怕的
磁盘或网络错误。因此，你可能已经找到了解决这个问题的方法，因为没有人想到过这个问题。
Now isn''t this interesting. However I do not *ever* recall any one with the dreaded
disk or network error ever trying this. Thus you may have hit upon a means of
getting around this problem because no one else has ever thought of this.
>发生此问题时，
用户与同一共享
驱动器中其他dbs的连接（读/写等）不受影响。
>When this problem occurrs, the
user''s connection (read/write etc) to other dbs in the same shared
drive are not affected.
哪些用户？其他用户？相同的用户？其他用户使用该应用程序的本地副本？
Tony
-
Tony Toews，Microsoft Access MVP
请仅在新闻组中回复，以便其他人可以阅读整个消息主题。
Microsoft Access Links，Hints，Tips&会计系统
http://www.granite.ab.ca /accsmstr.htm
Tony的Microsoft Access博客 - http://msmvps.com/blogs/access/
这篇关于终端服务器上的磁盘或网络错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
