Continuous corruption of database

G

Guest

I created a networked database (Access 2000 on Windows XP) where I keep the
front and back end both on the server, but they are seperate. Because the
database is new and am still making changes, for convenience for now I have
everyone using the same front end on the server. There are about 3 or 4 PC's
accessing the database at one time, but for some reason, the person that uses
it the most ends up corrupting the database approx once or sometimes more a
day when she's using her scroll on her mouse. I replaced the mouse with one
that doesn't have a scroll and it still happened. It has corrupted during
other times, but mostly when scrolling. I have other heavily used networked
databases that have run for years with corruption only about twice a year.
What have I done wrong? Where do I begin to debug this problem? The
corruption has strictly been on the backend. I plan to have the one PC
reimaged today to eliminate whether it's an Access or Windows issue.
 
L

Lynn Trapp

I created a networked database (Access 2000 on Windows XP) where I keep the
front and back end both on the server, but they are seperate. Because the
database is new and am still making changes, for convenience for now I
have
everyone using the same front end on the server.

That's your first mistake. Multiple users opening the same frontend is a
formula for corruption. Give each user their own frontend.
What have I done wrong? Where do I begin to debug this problem? The
corruption has strictly been on the backend.

Other than having all user opening the same frontend, I can't say what you
did wrong. If the corruption is truly in the backend, then you need to get
that corrected or it will continue to get worse. Start by importing the
entire backend into a new database to see if that corrects the problem.
 
G

Guest

Thank you, I had a feeling you would tell me that. I just gave each PC their
own front end, but that poses another issue. What is the easiest and
quickest way to pass a new front end to all the PC's throughout the building
other than going around to each one individually? E-mail is not a good
option due to these are generic workstations where e-mail is rarely accessed.
If they get another corruption today, I'll try to get more specific details
 
G

Guest

Hi Keeler,

Here are links to two good sites for investigating the causes of JET
database corruption:

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

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

As for distributing new updates to the FE database, you have a couple of
options. Tony Toews has a free utility known as the Auto FE Updater that is
mentioned quite frequently in this newsgroup:
http://www.granite.ab.ca/access/autofe.htm

Another option is to call a function in the FE database, which will pull an
update. This is usually done by comparing a version number stored in a local
table in the FE, with a version number stored in the BE database. If the FE
version is less than the current BE version, then you call the
UpdateFEVersion function. The code shown below currently includes a
hard-coded path to the new FE database (strSourceFile). A more flexible
method would involve storing the path to the new FE in a local table.

**********Begin Code (watch for word wrap)****************

Option Compare Database
Option Explicit

Declare Function apiCopyFile Lib "KERNEL32" Alias "CopyFileA" _
(ByVal lpExistingFileName As String, _
ByVal lpNewFileName As String, _
ByVal bFailIfExists As Long) As Long


Public Function UpdateFEVersion()
On Error GoTo ProcError

Dim strSourceFile As String
Dim strDestFile As String
Dim strAccessExePath As String
Dim lngResult As Long

'Create the source's path and file name.
strSourceFile = "\\server\share\YourFEDatabase.mde"
strDestFile = CurrentProject.FullName

'Determine path of current Access executable
strAccessExePath = SysCmd(acSysCmdAccessDir) & "MSAccess.exe "


If Dir(strSourceFile) = "" Then 'Something is wrong and the file
is not there.
MsgBox "The file:" & vbCrLf & Chr(34) & strSourceFile &
Chr(34) & vbCrLf & vbCrLf & _
" is not valid file name. Please see your
Administrator.", _
vbCritical, "Error Updating To New Version..."
GoTo ExitProc
Else 'copy the new version of app over the existing one.
lngResult = apiCopyFile(strSourceFile, strDestFile, False)
End If

'Modify strDestFile slightly so that it can be used with the Shell
function
strDestFile = """" & strDestFile & """"

MsgBox "Application Updated. Please wait while the application
restarts.", _
vbInformation, "Update Successful"

'Load new version, then close old one.
Shell strAccessExePath & strDestFile & "", vbMaximizedFocus

DoCmd.Quit

ExitProc:
Exit Function
ProcError:
MsgBox "Error " & Err.Number & ": " & Err.Description, , _
"Error in TestFEVersion event procedure..."
Resume ExitProc
End Function

**********End Code**********************************


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

:

Thank you, I had a feeling you would tell me that. I just gave each PC their
own front end, but that poses another issue. What is the easiest and
quickest way to pass a new front end to all the PC's throughout the building
other than going around to each one individually? E-mail is not a good
option due to these are generic workstations where e-mail is rarely accessed.
If they get another corruption today, I'll try to get more specific details
I created a networked database (Access 2000 on Windows XP) where I keep the
front and back end both on the server, but they are seperate. Because the
database is new and am still making changes, for convenience for now I
have
everyone using the same front end on the server.

That's your first mistake. Multiple users opening the same frontend is a
formula for corruption. Give each user their own frontend.
What have I done wrong? Where do I begin to debug this problem? The
corruption has strictly been on the backend.

Other than having all user opening the same frontend, I can't say what you
did wrong. If the corruption is truly in the backend, then you need to get
that corrected or it will continue to get worse. Start by importing the
entire backend into a new database to see if that corrects the problem.
 
G

Guest

Thanks a lot for your help on this. So far no crashes today! I appreciate
the tip on the Auto FE Updater. I'm looking into it now. This was all very
helpful, I hope it works.
Jeff
 
G

Guest

I had a corruption again today from the same person. I set everyone up with
the suggested Auto FE Updater (thanks again for that advice, it works great
once I figured it out) and gave everyone their own front end. They went a
few days without corruption until today. When she scrolled, she got an
"invalid argument" and it locked her up and corrupted the database. Do you
think I need to have the PC reimaged back to the original image and start
fresh, do you think something in Windows has gotten corrupted? Couldn't be
the mouse, because I switched it out and it still happened.
 
G

Guest

Hi Keeler,

In addition to Lynn Trapp's reply on disabling the mouse wheel, your
database might have some subtle form of corruption that is rearing it's ugly
head. Try the following steps on a copy of the shared BE database. These are
my general instructions, copied from another posting, for an unsplit
database; you will likely find that not everything applies to a data only
database:

Create a new database, and then import all objects, one group at a time,
into your new database. 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. Recreate any linked tables from scratch. When importing local
tables, make sure to check the option to import relationships, menus and
toolsbars, 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. You should disable
Name Autocorrect after creating the new container database. 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, and setting startup options and 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. You want to re-create any linked tables from
scratch, because Access can cache a lot of information about the links. Some
of this infomation may no longer be valid, so it's always best to recreate
the linked tables from scratch.

*****************
If corruption continues, especially from one individual, then it's time to
start checking out their personal practices (ie. proper exiting of the DB),
along with thier hardware. They may have a bad network interface card, or
some other problem in the network (network cable, router, etc.).


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

:

I had a corruption again today from the same person. I set everyone up with
the suggested Auto FE Updater (thanks again for that advice, it works great
once I figured it out) and gave everyone their own front end. They went a
few days without corruption until today. When she scrolled, she got an
"invalid argument" and it locked her up and corrupted the database. Do you
think I need to have the PC reimaged back to the original image and start
fresh, do you think something in Windows has gotten corrupted? Couldn't be
the mouse, because I switched it out and it still happened.
 
L

Larry Linson

use ACCESS DATA PROJECTS and you won't have this problem

But there are plenty enough problems with ADPs that many no longer use them.
I don't know aaron's level of experience with MDB and ADP; I know I have
used MDB/MDE front ends a lot with server databases, and ADP to a lesser
extent. I found nothing that would convince me to start a new development
project with ADP.

Don't expect them to "be the future of Access" -- definitely don't hold your
breath waiting for this to be the case in the next release; after all, we
don't want to lose Access users, even ones who are ADP bigots. <G>

Larry Linson
Microsoft Access MVP
 
G

Guest

Tom,
Thanks for the input, it was very useful. I was able to get everyone off
the system and did it last night, so I will write back what the results are
after a week. The only part I didn't get was the "set the checked references
to match the source database". I guessed that you were referring to me
pointing the front end back to the back end, but am not positive. Thanks
again for your help, I hope this does it.
 
G

Guest

Hi Keeler,
The only part I didn't get was the "set the checked references to match
the source database". I guessed that you were referring to me pointing
the front end back to the back end, but am not positive.

No, that part would have been covered with the statement "Recreate any
linked tables from scratch." Remember, I gave general instructions for an
*unsplit* database. You shouldn't need to worry about any references for the
back-end (BE) database. Setting the checked references to match the source
database is applicable to the front-end (FE) database only. You use ALT F11
to open the Visual Basic Editor (VBE). While in the VBE, you click on Tools >
References. This should reveal a list of checked library references. The best
thing to do is to set the same order, or priority, of the references. The
reason I say this is that it is very common for me to find code that uses
ambiguous declarations. For more on this topic, please refer to the link
shown below:

ADO and DAO Library References in Access Databases
http://www.access.qbuilt.com/html/gem_tips1.html

After verifying that the checked references match the source database, you
should attempt to compile the code in the new database, using Debug > Compile
ProjectName.

A couple of points that I missed:
1.) If you are missing Option Explicit as the second line of code in your
modules, then you should add this one module at a time. Do a Debug > Compile
each time you add this statement, and fix any compile errors that result
before moving on to the next module. For more information on this, please see
the following link:

Always Use Option Explicit
http://www.access.qbuilt.com/html/gem_tips.html#VBEOptions

2.) When linking tables in a multi-user database, it is best to use the UNC
(Uniform Naming Convention) path to the BE database, instead of using a path
that includes a mapped drive letter. UNC paths look like this: \\Server\Share

3.) Create a .mde version of your FE database prior to distributing it to
your users. Make sure to retain the .mdb version of the database, because
that's what you'll need to make any design changes to forms, reports or
modules in the FE. If you have problems creating an .mde, please see the
following link:

Cannot make .MDE
http://www.access.qbuilt.com/html/conversion.html#CannotMakeMDE

Note that there is no need to convert the BE database to a .mde format. This
doesn't buy you anything.

Good Luck, and please do report your results back.

Tom

http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

:

Tom,
Thanks for the input, it was very useful. I was able to get everyone off
the system and did it last night, so I will write back what the results are
after a week. The only part I didn't get was the "set the checked references
to match the source database". I guessed that you were referring to me
pointing the front end back to the back end, but am not positive. Thanks
again for your help, I hope this does it.
 
G

Guest

Hi Tom,
I'm back, unfortunately without happy results. I'm about at my wits ends
with this database and am very frustrated. I've tried about everything and
it's still getting corrupted. My latest attemps have been that I've had one
desktop reimaged back to original thinking it could be a corrupted OS file
that was causing the mouse to corrupt the database. I thought maybe a
wireless laptop was disconnecting from the network and causing the database
to corrupt. I hardwired the laptop and it still got corrupted. This morning
I created a new database from scratch AGAIN and imported in the files as you
suggested earlier. This time I did not bring the main data back into it, I
only imported the structure, thinking that old data may be causing a problem.
I then did the best I could to follow your latest instructions. History on
this database, this was not my original database in the beginning, but I took
the original tables and created my own forms, queres, reports, macros, etc.
so I'm not sure if it was created in Access 97 or not. Data goes back to
2003, that's all I know. Because of that, I did your instructions on adding
the DAO 3.6 to the VBE. I got a little lost with your instructions from that
point. I couldn't compile the code, the selection seemed grayed out. I also
don't have any modules, so I think your suggestion on adding Option Explicit
doesn't fit for my situation. As for the Uniform Naming Convention, I'm just
pointing to the BE using the linking in Access, I do not have drive letters
hard coded. I did not make the front end a .mde file. I don't feel real
confident, after everything else I've done, that this will make the
difference for me.

Again, I'm very frustrated and am about to tell them to go back to paper and
pencil because this database going down once a day is making me look real bad
right about now and they're getting frustrated with the system and as a
result, me. Any other suggestions to try would be greatly appreciated. I
really don't know where to go from here with the exception of punting.
Should I start messing with the record locking? I currently have it set to
the defaults. Thanks.
 
G

Guest

Hi Jeff,
I've tried about everything and it's still getting corrupted.
Have you looked into possible hardware issues. The last part of the reply I
wrote on 10/14 includes the following:

"If corruption continues, especially from one individual, then it's time to
start checking out their personal practices (ie. proper exiting of the DB),
along with thier hardware. They may have a bad network interface card, or
some other problem in the network (network cable, router, etc.)."

Is the file server on a UPS (Uninterruptable Power Supply)? If you are in
an industrial environment, with motors that draw a lot of current when they
start, you could be getting voltage line sags that are enough to account for
this type of corruption. This would apply to your users as well. I know of
one case where a PC was plugged into the same circuit as a vending machine.
The database would get corrupted every time break time came around. As
employees were purchasing cans of pop from the vending machine, the voltage
sagged just enough to cause corruption in the JET database.
I thought maybe a wireless laptop was disconnecting from the network
and causing the database to corrupt.
You need to ask, beg, demand, etc. that people *never* open your database
with a wireless connection. This is an inherantly unstable setup. JET
databases are just not suitable in such an environment. If your users insist
on using wireless connectivity, then you need to insist on migrating the BE
database to SQL Server.
I hardwired the laptop and it still got corrupted.
It might have already been corrupted from the wireless activity.
I couldn't compile the code, the selection seemed grayed out. I also
don't have any modules, so I think your suggestion on adding Option Explicit
doesn't fit for my situation.
The selection will be greyed out if the code is already compiled. Are you
sure that you have absolutely no code behind any forms and reports? If you,
or someone previous, ever used the command button wizard to add a command
button to a form, then you more than likely have some VBA code in your
project. Create a new stand-alone module. While in the VBE (Visual Basic
Editor) environment, click on View > Project Explorer. Do you see any forms
or reports displayed? If so, these forms and reports have code modules
associated with them. They may very well be empty modules, in which case they
can be deleted.
As for the Uniform Naming Convention, I'm just pointing to the BE using
the linking in Access, I do not have drive letters hard coded.
The linked table manager uses hard-coded drive letters unless you navigate
through My Network Places. If you click on Tools > Database Utilities >
Linked Table Manager, and you see a drive letter specified at the beginning
of the path, then you are indeed using hard-coded drive letters.
Should I start messing with the record locking?
Not at this time. I would solve the corruption problem first.

If you can compact and zip a copy of your front-end and back-end files, and
send them to me, I will take a look at them for you. A slightly obfuscated
form of my e-mail address is shown below. It should have 18 characters total,
after you remove the indicated characters. Whatever you do, please do not
post your real e-mail address to any newsgroup message.


Tom
QWaos168@XScom cast. Dnet (<--Remove all capitalized letters and spaces).
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

:

Hi Tom,
I'm back, unfortunately without happy results. I'm about at my wits ends
with this database and am very frustrated. I've tried about everything and
it's still getting corrupted. My latest attemps have been that I've had one
desktop reimaged back to original thinking it could be a corrupted OS file
that was causing the mouse to corrupt the database. I thought maybe a
wireless laptop was disconnecting from the network and causing the database
to corrupt. I hardwired the laptop and it still got corrupted. This morning
I created a new database from scratch AGAIN and imported in the files as you
suggested earlier. This time I did not bring the main data back into it, I
only imported the structure, thinking that old data may be causing a problem.
I then did the best I could to follow your latest instructions. History on
this database, this was not my original database in the beginning, but I took
the original tables and created my own forms, queres, reports, macros, etc.
so I'm not sure if it was created in Access 97 or not. Data goes back to
2003, that's all I know. Because of that, I did your instructions on adding
the DAO 3.6 to the VBE. I got a little lost with your instructions from that
point. I couldn't compile the code, the selection seemed grayed out. I also
don't have any modules, so I think your suggestion on adding Option Explicit
doesn't fit for my situation. As for the Uniform Naming Convention, I'm just
pointing to the BE using the linking in Access, I do not have drive letters
hard coded. I did not make the front end a .mde file. I don't feel real
confident, after everything else I've done, that this will make the
difference for me.

Again, I'm very frustrated and am about to tell them to go back to paper and
pencil because this database going down once a day is making me look real bad
right about now and they're getting frustrated with the system and as a
result, me. Any other suggestions to try would be greatly appreciated. I
really don't know where to go from here with the exception of punting.
Should I start messing with the record locking? I currently have it set to
the defaults. Thanks.
 
G

Guest

Tom,
Your advice has been wonderful and I greatly appreciate you sticking with me
on this. I will work on sending you an e-mail later with the database.
Thank you for that offer, you've gone above and beyond with your help. I
need to clean up the data a little bit because I work in a hospital and due
to HIPAA regulations, I'll need to get out the patient information before
sending it to you.

It's hard to tell if it's one PC that is causing the problem. When it goes
down, it goes down for all. I've reimage one potential problem PC and today
I'm cutting them off completely and am having them go back to paper for a few
days to see if it makes a difference.

Because I work in a large hospital, yes, the servers are on UPS. There are
no laptops on wireless right now. After I hardwired the laptop, I created a
new database and didn't import in any data (I am archiving all old and
starting a new one from this day on), so the wireless would not have
corrupted the database.

Since we were strictly working on the BE, I assumed that was the part that
you wanted compiled. I just ran it on the front end and it had one error,
but it was in code that wasn't being used, it was from the old program and I
eliminated those fields.

Got another corruption after I made all the changes this morning and wrote
the last e-mail. I have since cut off a main user and seeing if that
eliminates the corruption. Thanks Tom, I'll work on getting you the file
next.

Keeler
 

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

Top