Errors

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I have had a small Access database in use for about 2 years now. It has
been working well, with the exception that we get occasional errors and
sometimes corruption requiring a compact/repair.

The db is stored on a network drive. We tried it both with the front end
stored on the client pc's, and also with the users sharing the same front
end. Our IT group, of course, knows Access was designed to have the front
end installed on client. However, we get the same errors either way.

There are about 5 users total at any one time. A total fo 10 users have
access to the db.

In researching the errors, they seem to have to do with connectivity, and
broken connections. Some seem to have to do with corrupted workspace
occupied by the db. Below is a list of errors we have received on more than
one occasion.

The errors are experienced by all users who are logged in at the time,
whether or not the front end is shared, or whether it's installed on the
clients.

I'd like to have some suggestions as to whether these are indeed
connectivity issues, or any other advice anyone may have. Thanks!

Errors:

Disk or network error.

#NAME (appears in all fields).

#DELETE (appears in all or some fields).

Auto ID number becomes scientific and exponential in value (e.g. next id #
should be 2345 but instead is something line 18989899334).

Chinese language characters appear in some fields with "Record Changed by
Another User" message poppping up.

"The Microsoft jet database engine could not find the object "Scripts".
Make sure the object exists and that you spell the name and the pathname
correctly."

"The changes you requested to the table were not successful because they
would create duplicate values in the index, primary key, or relationship.
Change the data in the field or fields that contain the duplicate data,
remove the index, or redefine the index to permit duplicate entries and try
again."

"There was an error executing the command" (happened while trying to click
on a switchboard entry).

"The macro (or its macro group) doesn't exist, or the macro is new but
hasn't been saved. Note that when you enter the macro group name, macro
name, syntax in an argument, you must specify the name the macro's macro
group was last saved under."

Many thanks,
Rosemary
 
Hi Rosemary,

You definately want to run with the FE installed one each client's local
hard drive. Here are a couple of good articles that discuss JET database
corruption. Perhaps you have a noisy network. JET is very sensitive to
interrupted writes:

Preventing Corruption (Allen Browne)
http://allenbrowne.com/ser-25.html

Corrupt Microsoft Access MDBs FAQ
http://www.granite.ab.ca/access/corruptmdbs.htm

I would verify that all users have the latest service packs for the
operating system, the version of Office you are using, and the JET database
engine (SP-8). Use this KB article as a guide in determining this:

How to keep a Jet 4.0 database in top working condition
http://support.microsoft.com/?id=303528

If you suspect minor corruption, now would probably be a good time to create
a brand new back-end (BE) and front-end (FE) .mdb files, starting with your
existing BE & FE files. Here is my standard blurb on how to do this:

Create a brand new database and immediately disable the NameAutocorrupt
feature (see: http://allenbrowne.com/bug-03.html for reasons why you want to
do this). Then import all objects from the suspect database into the new
database, one group at a time. In other words, import all tables (but not
linked tables), then import all queries, then all forms, etc. While Access
will allow you to import all objects in one operation, the experts at FMS,
Inc. (a Microsoft Partner), have stated that it is best to import objects one
group at a time (Reference:
http://www.fmsinc.com/ubb/Forum12/HTML/000285.html).

Recreate any linked tables from scratch. Access can cache a lot of
information about linked tables, which may no longer be valid, so it's always
best to recreate the linked tables from scratch. When importing local tables,
make sure to check the option to import relationships, menus and toolbars,
and import/export specs. If any of the local tables in the source DB are
hidden, you'll need to first unhide them. You will need to set the checked
references to match the source database, along with any startup options set
under Tools > Startup. Going through this process often times solves
corruption problems, because you get a new set of the hidden system tables
(the tables whose names start with "MSYS"). These system tables are updated
appropriately as you import objects.

This may sound like a lot of work, but it really isn't. Creating a new
container DB, disabling NameAutocorrect, importing all objects one group at a
time, re-establishing any linked tables, setting startup options, and setting
references to match the source DB is usually a fairly quick procedure. When
you are in the Visual Basic Editor, in order to check that the references
match the source DB, you should do a Debug > Compile ProjectName as well.


The appearance of "Chinese language characters" suggests corruption as well.
Actually, these are not anything that a Chinese person could read, but just
random junk. Do you have any fields in your tables with the memo, hyperlink
or OLE Object data types? The reason I ask is that you may want to break
these out to a separate table, related 1:1, instead of storing them in your
table. That way, if one of these fields corrupts, you can usually recover the
rest of the record. Also, note that record-level locking is not enabled when
Memo data types are present.

Source: http://support.microsoft.com/kb/275561, under the title:
"Record-level locking".

Hyperlink and OLE Object data types involve the same pointer mechanism that
memo data types use, so I suspect that the same limitation regarding record
level locking applies if either of these two data types are present.

Use this article as a guide:

Implementing a Successful Multiuser Access/JET Application
http://www.access.qbuilt.com/html/multiuser_applications.html


Good Luck,

Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________
 
Rosemary said:
We tried it both with the front end
stored on the client pc's, and also with the users sharing the same front
end.

*Never* share the front end. You risk corruption.
Disk or network error.

Suspect faulty network equipment unless at least one of the users opened the
database with Access 2000 SP2 or lower and any computer that opened the
database has Office XP or Office 2003 installed.
#NAME (appears in all fields).

You have at least one missing reference. Often happens when more than one
version of Access is used by your users.
#DELETE (appears in all or some fields).

Could be another user deleted that record since the current user opened the
form (but only if it happens to all fields in a certain table, or multiple
tables if you've got cascade delete turned on), or this record is corrupted.
Auto ID number becomes scientific and exponential in value

Make the text box or column wider to get rid of exponents.
(e.g. next id #
should be 2345 but instead is something line 18989899334).

Suspect corruption. Does everyone have Jet 4.0 SP8 and the latest version of
MDAC?
Chinese language characters appear in some fields

Suspect corruption.
"The Microsoft jet database engine could not find the object "Scripts".
Make sure the object exists and that you spell the name and the pathname
correctly."

Most of the time this is developer error but it can be caused by corruption
too.
"The changes you requested to the table were not successful because they
would create duplicate values in the index, primary key, or relationship.
Change the data in the field or fields that contain the duplicate data,
remove the index, or redefine the index to permit duplicate entries and try
again."

Most of the time this is from poor design but it can be caused by corruption
too.
"There was an error executing the command" (happened while trying to click
on a switchboard entry).

You have to step through the code to find out what failed.
"The macro (or its macro group) doesn't exist, or the macro is new but
hasn't been saved. Note that when you enter the macro group name, macro
name, syntax in an argument, you must specify the name the macro's macro
group was last saved under."

This message is always true. If you *had* a macro by that name it's not
there anymore.
 
Thank you, Tom!

Tom Wickerath said:
Hi Rosemary,

You definately want to run with the FE installed one each client's local
hard drive. Here are a couple of good articles that discuss JET database
corruption. Perhaps you have a noisy network. JET is very sensitive to
interrupted writes:

Preventing Corruption (Allen Browne)
http://allenbrowne.com/ser-25.html

Corrupt Microsoft Access MDBs FAQ
http://www.granite.ab.ca/access/corruptmdbs.htm

I would verify that all users have the latest service packs for the
operating system, the version of Office you are using, and the JET database
engine (SP-8). Use this KB article as a guide in determining this:

How to keep a Jet 4.0 database in top working condition
http://support.microsoft.com/?id=303528

If you suspect minor corruption, now would probably be a good time to create
a brand new back-end (BE) and front-end (FE) .mdb files, starting with your
existing BE & FE files. Here is my standard blurb on how to do this:

Create a brand new database and immediately disable the NameAutocorrupt
feature (see: http://allenbrowne.com/bug-03.html for reasons why you want to
do this). Then import all objects from the suspect database into the new
database, one group at a time. In other words, import all tables (but not
linked tables), then import all queries, then all forms, etc. While Access
will allow you to import all objects in one operation, the experts at FMS,
Inc. (a Microsoft Partner), have stated that it is best to import objects one
group at a time (Reference:
http://www.fmsinc.com/ubb/Forum12/HTML/000285.html).

Recreate any linked tables from scratch. Access can cache a lot of
information about linked tables, which may no longer be valid, so it's always
best to recreate the linked tables from scratch. When importing local tables,
make sure to check the option to import relationships, menus and toolbars,
and import/export specs. If any of the local tables in the source DB are
hidden, you'll need to first unhide them. You will need to set the checked
references to match the source database, along with any startup options set
under Tools > Startup. Going through this process often times solves
corruption problems, because you get a new set of the hidden system tables
(the tables whose names start with "MSYS"). These system tables are updated
appropriately as you import objects.

This may sound like a lot of work, but it really isn't. Creating a new
container DB, disabling NameAutocorrect, importing all objects one group at a
time, re-establishing any linked tables, setting startup options, and setting
references to match the source DB is usually a fairly quick procedure. When
you are in the Visual Basic Editor, in order to check that the references
match the source DB, you should do a Debug > Compile ProjectName as well.


The appearance of "Chinese language characters" suggests corruption as well.
Actually, these are not anything that a Chinese person could read, but just
random junk. Do you have any fields in your tables with the memo, hyperlink
or OLE Object data types? The reason I ask is that you may want to break
these out to a separate table, related 1:1, instead of storing them in your
table. That way, if one of these fields corrupts, you can usually recover the
rest of the record. Also, note that record-level locking is not enabled when
Memo data types are present.

Source: http://support.microsoft.com/kb/275561, under the title:
"Record-level locking".

Hyperlink and OLE Object data types involve the same pointer mechanism that
memo data types use, so I suspect that the same limitation regarding record
level locking applies if either of these two data types are present.

Use this article as a guide:

Implementing a Successful Multiuser Access/JET Application
http://www.access.qbuilt.com/html/multiuser_applications.html


Good Luck,

Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________
 
Thank you!

Granny Spitz via AccessMonster.com said:
*Never* share the front end. You risk corruption.


Suspect faulty network equipment unless at least one of the users opened the
database with Access 2000 SP2 or lower and any computer that opened the
database has Office XP or Office 2003 installed.


You have at least one missing reference. Often happens when more than one
version of Access is used by your users.


Could be another user deleted that record since the current user opened the
form (but only if it happens to all fields in a certain table, or multiple
tables if you've got cascade delete turned on), or this record is corrupted.


Make the text box or column wider to get rid of exponents.


Suspect corruption. Does everyone have Jet 4.0 SP8 and the latest version of
MDAC?


Suspect corruption.


Most of the time this is developer error but it can be caused by corruption
too.


Most of the time this is from poor design but it can be caused by corruption
too.


You have to step through the code to find out what failed.


This message is always true. If you *had* a macro by that name it's not
there anymore.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top