Disk or Network error on Terminal Server

[gary0gilbert]

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.

[paii, Ron]

<ga**********@gmail.comwrote in message
news:3c**********************************@i29g2000 prf.googlegroups.com...

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.

Take a look at MicroSoft KB article 889588.

Do you have a persistent connection between the front-end and back-end
database?

[gary0gilbert]

On Feb 18, 12:58*pm, "paii, Ron" <[e-mail]:

<[e-mail] in message

news:3c**********************************@i29g2000 prf.googlegroups.com...

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.

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 -

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.

[Tony Toews [MVP]]

ga**********@gmail.com wrote:

>An unusual spin to this recurring disk or network error in a Terminal
Server environment.

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?

>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.

>When this problem occurrs, the
user's connection (read/write etc) to other dbs in the same shared
drive are not affected.

Which users? Other users? Same users? Other users with local copies of the app?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

[Tony Toews [MVP]]

"paii, Ron" <no**@no.comwrote:

>Take a look at MicroSoft KB article 889588.

Do you have a persistent connection between the front-end and back-end
database?

While the above is very useful along with the Access Performance FAQ page at
http://www.granite.ab.ca/access/performancefaq.htm I don't feel it is relevant in
this situation.

Tony

--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

[gary0gilbert]

On Feb 19, 5:11*pm, "Tony Toews [MVP]" <[e-mail]:

[e-mail] wrote:

An unusual spin to this recurring disk or network error in a Terminal
Server environment. *

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.

Both of our Terminal Servers have one network connection. These are
plugged into the same 10/100/1000 switch section that all of our
servers use.

>
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.

Yes, the file server is on the same switch section, although (and i
laughingly hesitate to bring this up because it has been a problem
both before AND now) our file server is on a virtual VMWare machine.
Our Terminal Servers are not.

>
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?

Several times we have had the network switch info reviewed, and each
time it showed no errors, no unusual dropped packet stats, etc during
the time period involved, or at any time for that matter.
Also, if this was a network hardware issue, i wonder why this only
affects a few of our most-used backend databases, and never our MOST
used backend db?
Side Note: I have re-built these backend dbs many times (blank copy
of db, imported all objects, repaired/compacted).

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 withthe 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.

I simply stumbled across this. Addl bit of info here. When the user
receives the disk/network error, not only is the linked table not
accessible from their front-end database, when trying to directly open
the backend database with a dbl-click in explorer, the disk/network
error displays. I was going to check the db security permissions
while there, and noticed the slight delay when right-clicking and
selecting properties. On a hunch, i then closed it, dbl-clicked the
backend db again, and presto! I immediately went back to their front-
end, and it worked fine. As i said, this has never failed to clear
the problem.

When this problem occurrs, the
user's connection (read/write etc) to other dbs in the same shared
drive are not affected.

Which users? *Other users? *Same users? *Other users with local copies of the app?

I have run into situations where *sometimes* other users have the same
problem at the same time, but usually it's one user only. The user
who is experiencing the problem can still read/write data to other
backend dbs linked to their local db copy. I don't think i have ever
run into a situation where the same user has more than 1 backend db
showing a disk/network error at the same time.

>
Tony
--
Tony Toews, Microsoft Access MVP
* *Please respond only in the newsgroups so that others can
read the entire thread of messages.
* *Microsoft Access Links, Hints, Tips & Accounting Systems athttp://www.granite.ab.ca/accsmstr.htm
* *Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/

[David W. Fenton]

"Tony Toews [MVP]" <tt****@telusplanet.netwrote in
news:or********************************@4ax.com:

ga**********@gmail.com wrote:

>>An unusual spin to this recurring disk or network error in a
Terminal Server environment.

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.

I've been saying for a very long time that hardware errors not at
all the only (or even most likely) cause of corruption. Software
configurations on the server can cause these problems. I learned
this with an Exchange Server hotfix back in 1999 that caused a
replicated MDB to lose replicability. The error first happened about
90 minutes after the hotfix was applied, and ceased forever the
minute the hotfix was backed out.

So, if this started happening recently, you need to look at the
history of patches to the server.

[discussion of NICs deleted]

Now your IT department are likely going to strenuously disgree
with my suggestion.

I'd dissent from your suggestion, too.

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.

....and other kinds of issues (like things that mess up the
redirector subsystems underlying SMB networking -- are the front
ends linked to the back end via UNC or local paths? If UNC, that
would finger the redirector layer, and might be resolved by mapping
local paths).

Can the IT department view any logs on those switches? Is there
anything else on their that they can review?

I think that would be directing them in the wrong direction, given
that:

>>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.

This seems to very clearly implicate something in the SMB networking
subsystem that is *software-based*, not hardware.

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.

I don't think it will work with the usual DISK OR NETWORK ERROR,
because those mean the disk or network share are inaccessible. This
leads me to believe the problem is entirely software- and not
hardware-based.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

ga**********@gmail.com wrote in
news:db**********************************@64g2000h sw.googlegroups.com
:

Also, if this was a network hardware issue, i wonder why this only
affects a few of our most-used backend databases, and never our
MOST used backend db?

Because I would say it's likely *not* a hardware issue.

Access is timing out trying to ping the back end. Keep in mind that
Access pings the back end/LDB file every 1 second (or whatever
you've set as your refresh interval), and when it doesn't get an
answer, it throws DISK OR NETWORK ERROR.

So, if there's some software issue mucking up the works, that can
cause Access to time out. And the reason Explorer works is because
it has a longer timeout interval.

I would first check the patch logs to see what updates have been
applied and if any of them happen to have been applied just before
the problem first started appearing.

After that, I'd start looking at the VMWare issue. If you're running
on top of a non-Windows OS, then there could be issues with the
underlying file system not behaving the way Windows expects. It's
possible that some kind of recent Windows patch could exacerbate
this problem so that it just showed up.

I'm very wary of hosting Access back ends on anything but a real
Windows file system. I know lots of people claim success with
Linux/Samba, but I'm afraid I'm just not brave enough to attempt it.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

ga**********@gmail.com wrote in
news:db**********************************@64g2000h sw.googlegroups.com
:

I have run into situations where *sometimes* other users have the
same problem at the same time, but usually it's one user only.
The user who is experiencing the problem can still read/write data
to other backend dbs linked to their local db copy. I don't think
i have ever run into a situation where the same user has more than
1 backend db showing a disk/network error at the same time.

This sounds like contention for file locks in the underlying file
system on the server is a bottleneck that causes Access to time out.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"Tony Toews [MVP]" <tt****@telusplanet.netwrote in
news:ai********************************@4ax.com:

"paii, Ron" <no**@no.comwrote:

>>Take a look at MicroSoft KB article 889588.

Do you have a persistent connection between the front-end and
back-end database?

While the above is very useful along with the Access Performance
FAQ page at http://www.granite.ab.ca/access/performancefaq.htm I
don't feel it is relevant in this situation.

It seems to me to be thinking in the right direction, just not
applicable to this case given the info. we've been given.

It seems pretty clear to me that Access is timing out trying to get
locks on either the LDB file or the MDB file (or both). That it
happens the more people are using that particular back end suggests
to me that there's a bottleneck in the underlying file system of the
server that the back end is stored on. One could quickly test this
by moving the back end to a Windows server with a pure Windows file
system (instead of running it on a virtualized Windows server
running on top of who-knows-what underlying file system).

So, if it weren't for the fact that we already know that the problem
is exacerbated by multiple users, we might finger the LDB creation
problem (which is what is solved with the persistent connection).
But the thinking is definitely heading in the right direction, in my
opinion.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

ga**********@gmail.com wrote in
news:16**********************************@34g2000h sz.googlegroups.com
:

On the Tools/
Options/Advanced tab, we have a 30/60/2/1500/250 for each of our
front- and back-end dbs. Suggestions on modifying this in light
of a possible timeout issue?

This is an Access application setting, not something that applies to
the MDB.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/