Access Database Corrupted on Unexpected Exe. Shutdown

[Jimmer]

I have a vb executable that works in a server/client environment. The Access database is stored on the server machine and the executable is run from the seperate client machines.

The problem I have is that if one on the client machines is shutdown unexpectably, and the executable is performing certain intense calculations, the next time I try to open the access database, the error of a corrupt database is displayed. Sometimes I can uncorrupt the database and other times I can't.

Any suggestions on how I can prevent the database from becoming corrupted in the first place?????

Thanks in Advance!
Jimmer

[Gary.Lowe]

Jimmer

Try wrapping all edits in transactions to keep everything tidy and in query unloads create code to see if the recordsets and database connections are still active.

If they close them snd set them to nothing.

that should stop corruption.

What version of Access are you using and datadase connection type?

Gazza

[Jimmer]

I am using Access 97 with DAO data controllers. I find that these data controllers are hard to close the connection with and have not found I good way to close the connection.
I've tried setting them to nothing but I keep getting an error. I am using a lot of TDBGrid to display my data and find that using the data controllers is the best way to do this, but I wonder whether I should be switching to ADO controllers??? But wonder whether this is a hard task to switch over or not??

What do you mean by wrapping all edits????

Thanks In Advance
Jimmer

[Magik]

ADO is definitely the way to go, however, changing an existing app may be more work than you want to take on, depending on the size of the app of course. ADO will give you more control and versatility in your apps. Would be a good switch to make whether it is on this app or future projects.

[Gary.Lowe]

Jimmer

If you are simply dispalying data from these grids set them to snapshots rather than dynasets.

If you need to update a record you can update the record in code by selecting the record based on the ID of that paticular record in the dDBGrid.

If you wrap the record in a transaction when editing this makes sure either the whole thing is updated of nothing is done at all.

The only time I use a data grid is if I am simply displaying
data. If i need to update a record I do this in code this way I have total control on what I am editing and total control over all the connections.

Gazza

[Jimmer]

Certain tables my Access 97 database will have massive amount of records and because of this I have been setting the recordsettype to 0-Table and using the indexes built in Access 97 to view the data. Will the snapshots be quicker than using these indexes, and could this be the cause of my problems with closing the database connections??? With switching to ADO, this would allow me to switch and use SQL Server 7.0 for my database design. Do you think this is a good idea????

[Magik]

As in my earlier post, ADO would give you more flexibilty, and control to do what you want to do. Yes you can use it for SQL databases, but you can use what you have now with SQL. ADO, in my opinion, is a much better way to go for any database application.

[JHausmann]

Originally posted by Jimmer
With switching to ADO, this would allow me to switch and use SQL Server 7.0 for my database design. Do you think this is a good idea????

If you think the database will ever be on SQL Server, definitely use ADO.