Neverending Database corruptions

[Drjb]

We have been having irregular database corruptions using QuickDoc--a psychotherapy clinical notes software program built on Access. We run the program from a dedicated server on a small network of five workstations. We've gone as long as six weeks without a problem. On the other hand, some days we may have to shut down three or four times to run Jetcomp. No changes in hardware, software, or users.

Corruptions are always easily fixed with JetComp but will recurr.

I know virtually nothing about Access--does this sort of problem sound familiar? Could there be small residual corruptions after JetComp "restores" the database to functional status that then serve as a foundation for subsequent problems?

Any help would be appreciated.

 

[Jason]

I am assuming that Quick Doc is a Access DB with both the Front and Back end in one DB File residing on the Server, with users opening that file concurrently. I have found similar problems in that type of environment. There are a couple of ways around it.

1: Go around to each computer and make sure that they have a: the exact same date formats set in the regional settings on each and b: make sure that they have all the neccessary references available, (IE go into the VB code editor and check the Tools, References section for any MISSING references - if there are then you would need to find the missing .dll or .ocx files and register them on the machine). This could solve your problem and the seemingly random corruption problem as one of the users could be corrupting the DB merely by opening it with incorrect references, or by accessing or entering dates in the wrong format.

2: The other thing you could do is split your DB into a Front End and Back End using the DB splitter in the Tools Menu option. This will allow you to place the FE on each clients computer with linked tables to the networked BE. You would still need to check that each of the Clients have the correct references and date formats however, this is the reccommended route to follow as it places the least overhead on the network.

3: If you still have prolems then it could be some sort of inherent problem within your DB itself, try creating a new DB and importing all your Forms, Reports, Modules, Macros, etc and re-creating the relationships. This should sort out any problems that may be underlying the DB itself.

Obviously there could be problems as the File may be compiled into an MDE file or there could be security settings that disallow you to access the References section. If so then you need to go down a security route to try and free the permissions on the DB. Perhaps contact the developers.

Hope that helps

Jay

 

[Pat Hartman]

Database corruption is frequently caused by users shutting down their PC's without closing Access. Most people don't do this intentionally. It happens if their system locks up and they need to reboot. It also happens if your network is flaky and the PCs loose their network connection. I had a situation where if my hard drive power saver feature was enabled. and I left a database open and the PC unattended long enough for the power saver feature to activate shutting down my hard drive, my PC would loose its network connection and thereby corrupt the db that I had open.

Suggestions:
1. Close the db when not actively in use.
2. Turn off the power saver if that is what is causing the lost network connection.
3. If you have the ability, split the application into a front and backend db structure and put the front end db on the users' C: drive.

 

[kitp]

Quic Doc

We also were having problems with QuicDoc data base. Four months of HELL and they said it had to be our equipment, etc, the problems magically disappeared when we upgraded to the SQL version.

Would love to compare notes. e-mail me.

 

[Shep]

You might find some relief by disabling Opportunistic Locking if your server is running NT 4.0, Windows 2000, or Novell.

KB Articles:
Q303519
Q296264
Q129202
Q109953

And others...


Shep

 

[Drjb]

Shep

I did disable opportunistic locking last week with great results. After rebooting, we've had no problems whatsoever with very high usage.

You're right on target!

 

[Shep]

I think the tipoff for us was the fact that I knew with certainty that our database was written with no record locking, yet we would see messages indicating that a record was locked.
This in addition to corruption with no apparent cause...

Glad to hear it, and happy that this information helped you.

Shep