Crashes in network environment

[michael rogovin]

Apologies to those who have seen this post before; the
problem is still unresolved.

I created several database applications in Access 2002.
They started as Access97 simple databases and were
converted to Access2002 format and then modified
extensively into full applications. The errors did not
occur before. The network setup is Access running on user
workstations (win xp) and the datafile for each
application on the fileserver (Windows 2000 network) with
edited record locking. The problems occur whether or not
the datafile is opened by one or more users.

When running the database, Access will suddenly lose the
datafile; that is, Access continues to run, but the
datafile is suddenly empty. There are no tables, queries,
etc--it is as if I just opened a new blank database. Any
form on screen no longer works, since there are no
macros, queries etc. associated with it. Typically this
is accompanied by multiple "Disk or Network Error"
message boxes which appear every few seconds until they
fill the screen and have to be closed one by one.
Sometimes there is no error. Once, I got a windows error
in the system task bar about a delayed write and lost
data which caused the same effect in Access. Sometimes
compacting and repairing reduces instances of the
problem, but they reoccur shrtly thereafter. I am not
aware of any other problems on the net (all my word,
excel and outlook files are on the server and I have
never seen this problem with those apps).

I have looked on the KB but found only articles related
to Access 2.0 or IIS, neither of which apply to my
situation. I also tried replacing the network cable per
suggestions from this forum, to no avail. Several users
of the applications on the network have experienced the
problem, so it is not localized to my workstation.

Does Access create a tmp file like Word does when it
opens a data file? If so where (I could not find it). If
so, is it possible that something is happening to the TMP
file during a session that would cause this error? Any
other ideas? We are at a loss and are concerned about
possible data loss on mission critical applications.

Thanks.

 

[Kevin3NF]

How many users? I'm just curious...

I have heard that if any piece of the network is flaky (cables, NICs, hubs,
etc) this can cause the issue, even if it is on a machine that does not use
the application.

Is it split into FE/BE, with the FE on each user's machine?

 

[Chris Newman]

Hi

Have you tried upsizing it to a MSDE backend and the Access ADP as a front
end?

Chris

 

[Zofia]

I have similar experience - only data bases became
corrupted and I need to repair. Repairing via ODBC works so
far (thanks for that suggestion Tony Toews) but I still do
not know how to address the cause. My data bases are
very simple, converted from 97, working in Windows 2000
environment. Installing service pack 4 as suggested did not
help... Sometime is works OK for 2 months and then crashes
5 times a day - no changes or any logical reason....Any
suggsstion - Help please!!!!

 

[Kevin3NF]

Database split into FE/BE? Terminal server involved?

There are a number of possible reasons for corruption...

 

[Tony Toews]

Have you tried upsizing it to a MSDE backend and the Access ADP as a front
end?

That's a lot of work for what is almost certainly either some kinda
hardware problem or an OpLocks problem.

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 Toews]

I created several database applications in Access 2002.
They started as Access97 simple databases and were
converted to Access2002 format and then modified
extensively into full applications. The errors did not
occur before. The network setup is Access running on user
workstations (win xp) and the datafile for each
application on the fileserver (Windows 2000 network) with
edited record locking. The problems occur whether or not
the datafile is opened by one or more users.

When running the database, Access will suddenly lose the
datafile; that is, Access continues to run, but the
datafile is suddenly empty. There are no tables, queries,
etc--it is as if I just opened a new blank database. Any
form on screen no longer works, since there are no
macros, queries etc. associated with it. Typically this
is accompanied by multiple "Disk or Network Error"
message boxes which appear every few seconds until they
fill the screen and have to be closed one by one.
Sometimes there is no error. Once, I got a windows error
in the system task bar about a delayed write and lost
data which caused the same effect in Access. Sometimes
compacting and repairing reduces instances of the
problem, but they reoccur shrtly thereafter. I am not
aware of any other problems on the net (all my word,
excel and outlook files are on the server and I have
never seen this problem with those apps).

I have looked on the KB but found only articles related
to Access 2.0 or IIS, neither of which apply to my
situation. I also tried replacing the network cable per
suggestions from this forum, to no avail. Several users
of the applications on the network have experienced the
problem, so it is not localized to my workstation.

1) The first thing to do is to split the the MDB into a front end
containing the queries, forms, reports, macros and modules with just
the tables and relationships. The FE is copied to each network users
computer. The FE MDB is linked to the tables in the back end MDB
which resides on a server. You make updates to the FE MDB and
distribute them to the users, likely as an MDE.

See the "Splitting your app into a front end and back end Tips" page
at my website for more info. See the Auto FE Updater downloads page
at my website to make this relatively painless.. It also supports
Terminal Server/Citrix quite nicely.

2) Disk or Network Error usually means flaky hardware but could be the
OpLocks problem. If multiple users as you state then I'd suspect a
switch/hub or the server connection.

Word, Excel, Outlook are different in that they usually only do
network traffic in bursts when you open or save a file. Access
however has a constant traffic flow and thus is very vulnerable to
intermittently flaky outages.

For more info on Corruption including a definition of the OpLocks
problem see the Corruption FAQ page at my website.

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

 

[Michael Rogovin]

Thanks. Will give it a try.

Michael

-----Original Message-----


1) The first thing to do is to split the the MDB into a front end
containing the queries, forms, reports, macros and modules with just
the tables and relationships. The FE is copied to each network users
computer. The FE MDB is linked to the tables in the back end MDB
which resides on a server. You make updates to the FE MDB and
distribute them to the users, likely as an MDE.

See the "Splitting your app into a front end and back end Tips" page
at my website for more info. See the Auto FE Updater downloads page
at my website to make this relatively painless.. It also supports
Terminal Server/Citrix quite nicely.

2) Disk or Network Error usually means flaky hardware but could be the
OpLocks problem. If multiple users as you state then I'd suspect a
switch/hub or the server connection.

Word, Excel, Outlook are different in that they usually only do
network traffic in bursts when you open or save a file. Access
however has a constant traffic flow and thus is very vulnerable to
intermittently flaky outages.

For more info on Corruption including a definition of the OpLocks
problem see the Corruption FAQ page at my website.

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
.