Access Crashing

[mugman17]

I have a client who is upset because the database crashes several times a week. It says that the system needs to be compacted and repaired. Normally, when I get the system sent back to me after something like this, I notice in the query list is the name of a form with something like this as a title:

sq_frmViewTotal_ ...

Is the form mentioned above corrupt? Or is the query behind that form which is corrupted? Or do I have a different problem here?

Thanks.

 

[casey]

I don't know if this helps, but...

When things are acting wierd in a database. In the past I have created a new database and imported everything from the original into the new database. Sometimes this works!

HTMS

 

[raffle]

Hi

Alot of things could be causing this.

You might want to check how the users are logging out.

I tend to have problems if a user switches the pc off while the access database is still open, this can sometimes lock it up.

Also the size of the database can cause problems, I have one that seems to go all pear shaped when it reaches 150mb.

Hope this helps

raffle

 

[The_Doc_Man]

You don't say if the database is shared via network or confined to a single system so some of what I suggest might not be right.

A common issue that crops up with Access that has to do with having to compress often is that you need enough memory and enough free disk space to do Save operations, queries, and other niceties.

Factors affecting this requirement include:

1. Do you have enough physical memory and swap space for Access to build a complete virtual image of the new database that you are about to save?

2. If you are on a networked drive, is a quota in effect for your folder and do you have at least as much free space as is required for the Save to create a new, unnamed copy of the database? (Access will later delete the old copy and rename the new one.)

3. Does your client have an established regimen of compression on a regular and frequent basis? Because, you see, Access does not voluntarily garbage-collect itself. Every temporary query you run chews up free space, causing Access databases to "bloat" like a puffer-fish in peril. The only way to reclaim the used space is to compress.

Now, the frequency of compression DIRECTLY AFFECTS the size requirements for my questions 1 and 2, because it is possible to have enough space/quota for a compressed version of the database, but not enough for one that has been allowed to bloat for a few days without cleanup.

Only you and your customer can establish the "bloat" rate for that database. Check the size each day, determine an average growth rate, evaluate the maximum size you can get before you are in deep doo-doo, and make sure you start a compression before things get too deep.