Repost: MS Access "Network or Disk error" message

[Damien McBain]

Sorry to repost, I think my OP was timed incorrectly so as to get too far
down the list before the reading time of the pros
=================================
Repost:

I have a multi-user (20-30 at a time) who access my db. The mdb and be.mdb
are located on a network share on our WAN (a large corporate network). The
mdw is in a different dir in the same share. All users access the mdb via
Citrix (the Citrix server is connected to the file server via LAN).

In the last couple of days it has developed a fault where users (including
me) get an Access error message stating "Network or Disk Error" when trying
to open the db, before the Access login dialog. There is nothing apparrently
wrong with the file server or the citrix server. The first time the error
occurred, it was the mdw file that was causing the issue (I could open the
mdb using a backup of the mdw). Today it was the mdb, I couldn't open it at
all but I could open the back end db.

Anyone seen this before? What's flaky here, Citrix, Access, the file server,
(my Database!)?. I found a couple of similar issues by Googling but nothing
that replicates my set of circumstances. Any pointers appreciated.

In my situation would I be better served developing a front-end with asp.net
rather than using a thin client? I am reluctant to run the front end on all
the client's machines since it's still very new and I upgrade it almost
every night (and the b/e is in another location).

Damo

 

[Allen Browne]

Alternative explanation might be that we don't use Access on a WAN.

See Albert Kallals' suggestions:
http://www.attcanada.net/~kallal.msn/Wan/Wans.html

 

[Damien McBain]

Alternative explanation might be that we don't use Access on a WAN.


See Albert Kallals' suggestions:
http://www.attcanada.net/~kallal.msn/Wan/Wans.html

A good article, same goes for the one he's linked
http://www.attcanada.net/~kallal.msn/Articles/ThinClientsand.net.html

So now I have to learn a new product :/ A bit tough for a simple sales
manager with an IT hobby and a small flair for user interfaces

Is 30 users too much for JET?

 

[imbd4a]

Allen,
I read your post and was wondering if the same holds true for a SQL back
end. I have recently developed an Access db. and migrated the back end to
our company sql server and pushed the front end client out on the WAN
directory. Seems to be working alright thus far, but like I said, just
wondering if problems may be in store as more users begin to hammer on it.
Thanks
Brian

 

[Allen Browne]

Hi Brian.

As I hinted, I don't use Access on a WAN.

The guys who do say that Terminal Server is acceptable. That way the session
runs on the server and so is not about to just fall over in the middle of a
write and corrupt the database like a WAN client session can.

If you are using SQL Server as the back end, it's more robust than JET
anyway, e.g. you could rollback if you did have a problem.

 

[Arvin Meyer]

Your database is probably corrupted, but you can usually fix that with a
compact and repair. Make sure you work on a copy. Have a look at Tony Toews'
Access Corruption FAQ at:

http://www.granite.ab.ca/access/corruptmdbs.htm

I have experience with up to 50 users on JET and up to 10 to 12 on a
terminal server. No problems. Here is the methodology:

1. A well designed database with proper indexing rarely corrupts without a
power failure. I've never seen a terminal services (or Citrix for that
matter) database, corrupt.

2. Make sure the database is split with linked tables to a front-end for
each user.

3. For Citrix or MS Terminal Server have a separate folder with a front-end
for each user. That is important.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads:
http://www.datastrat.com
http://www.mvps.org/access

 

[Albert D. Kallal]

I have a multi-user (20-30 at a time) who access my db. The mdb and be.mdb
are located on a network share on our WAN (a large corporate network). The
mdw is in a different dir in the same share. All users access the mdb via
Citrix (the Citrix server is connected to the file server via LAN).

You need ensure that EACH user has a copy of the FE. Of course you are using
Citrix, so the rule STILL applies that each user gets their own copy of the
FE...but they are on Citrix.

I am reluctant to run the front end on all
the client's machines since it's still very new and I upgrade it almost
every night (and the b/e is in another location).

No, you can't do the above...but your setup of Citrix (which by the way is
the same as terminal services) is a good one. So, two things here:


Users should get a mde, not a mdb
And DO NOT allow multiple users into the same front end.. The fact that the
FE in on the citrix box does not change this rule. So, don't get confused by
the suggestion to give each user a FE.....you still do this when using
Citrix.

 

[Albert D. Kallal]

Allen,
I read your post and was wondering if the same holds true for a SQL back
end. I have recently developed an Access db. and migrated the back end to
our company sql server and pushed the front end client out on the WAN
directory. Seems to be working alright thus far, but like I said, just
wondering if problems may be in store as more users begin to hammer on it.
Thanks
Brian

The above sql part is a fine setup, and your only limits are that of sql
server. Sql server is very good, so you should not have any problems here.

However, you MUST NOT allow multiple users into the front end. That front
end should be mde, and EACH USER gets a copy. Do not run the FE across the
lan, and do not allow multiple users into a copy of the FE. That FE must get
installed on each pc, or you will experience stability problems.

 

[Damien McBain]

Thanks everyone - the common theme seems to be a separate mde fe for each
user. That's gonna be a pain in the arse but not as bad as having the thing
shit itself every day.

Looks like it's time to learn ASP.NET!

cheers

Damo

 

[Tony Toews]

Thanks everyone - the common theme seems to be a separate mde fe for each
user. That's gonna be a pain in the arse but not as bad as having the thing
shit itself every day.

I specifically created the Auto FE Updater utility so that I could
make changes to the FE MDE as often as I wanted and be quite confident
that the next time someone went to run the app that it would pull in
the latest version. For more info on the errors or the Auto FE
Updater utility see the free Auto FE Updater utility at
http://www.granite.ab.ca/access/autofe.htm at my website to keep the
FE on each PC up to date.

In a Terminal Server or Citrix environment the Auto FE Updater now
supports creating a directory named after the user on a server. Given
a choice put the FE on the Citrix server to reduce network traffic and
to avoid having to load objects over the network which can be somewhat
sluggish.

Looks like it's time to learn ASP.NET!

Why? Development time could be three times as much or more.

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

 

[Damien McBain]

I specifically created the Auto FE Updater utility so that I could
make changes to the FE MDE as often as I wanted and be quite confident
that the next time someone went to run the app that it would pull in
the latest version. For more info on the errors or the Auto FE
Updater utility see the free Auto FE Updater utility at
http://www.granite.ab.ca/access/autofe.htm at my website to keep the
FE on each PC up to date.

In a Terminal Server or Citrix environment the Auto FE Updater now
supports creating a directory named after the user on a server. Given
a choice put the FE on the Citrix server to reduce network traffic and
to avoid having to load objects over the network which can be somewhat
sluggish.


Why? Development time could be three times as much or more.

Tony

Tony, I'm just now reading your web page
http://www.granite.ab.ca/access/autofe/details.htm

I'm unclear as to what you are recommending as far as the location of the
mdw goes. I am copying it onto the clients but I think you're saying it
should be located on the server?
This is unfortunately one of the files I had trouble with when everyone was
using the same one over the Citrix connection. (I have today deployed mde's
for each user with Access installed).