MDB File Corruptions
Greg Maass
You might want to make sure you are closing all of your database and
recordset objects, setting them to nothing, and issuing dbengine.idle
dbfreelocks statements after dabatase writes. Sometimes lingering DB locks
can cause problems....
William W. Lowe <meta...@mindspring.com> wrote in article
<3403f362...@news.mindspring.com>...
>
> I am looking for any information anyone may have about possible
> code-based causes of Jet 3.0 (32-bit) data file corruptions.
>
> I have a fairly complex VB4 multiuser data application, available in
> both 16-bit and 32-bit versions, which uses plain-vanilla Jet 3.0 and
> DAO. One of my clients is having frequent problems with MDB file
> corruptions at some (not all) of their 50-odd installations. Some of
> these site are experiencing corruptions as often as 1-2 times per week
> (in no particular pattern, of course). Other clients (16-bit and
> 32-bit) are not reporting unusual problems (of course, they may be
> occurring).
>
> The client having the problems has its own IS department which manages
> all their installations, so they (presumably) don't have inexperienced
> users messing with their installations. All of their sites are using
> the 32-bit version of the app, and all are using NT on the server and
> NT or 95 on their workstations. Most sites DO use the server as a
> workstation, but at least one site having problems does not.
>
> These guys know their stuff, and they have pretty well investigated
> all the possible causes *external* to my application (although they
> have obviously not absolutely ruled out such). I recognize that using
> the server as a workstation is not ideal; they know this too, but
> hardware costs money.
>
> Given the above, they have reasonably questioned whether my app may be
> the culprit. So:
>
> 1. Is it possible for standard VB code to cause data file
> corruptions (aside from bugs which cause the program to hang, etc.).
>
> 2. If so, what kinds of code might do this.
>
> 3. Any suggestions or thoughts would be appreciated.
>
> Thanks,
>
> Bill Lowe
> wl...@ms-systems.com
>
>
>
Manuel Teixeira
Hi,
Make sure you allways close your data access objects and set them to
nothing:
Dim db as database
Dim rs as recordset
set db=....
set rs=db.open......
your code
rs.close
set rs=nothing
db.close
set db=nothing
In some cases not cleaning up may cause the database to become
corrupted. Also if your program hangs the data access objects may not
be closed. So a good technique is having error handling everywhere.
Make sure that if you need to use the End statment that everything is
closed.
Avoid having objects open for the duration of the App. close them as
soon as you don't need them.
Some times you have to terminate the App due to some system failure
(Printer off-line per example). It's quite common to do this and
forget that you have open objects elsewhere. Include some kind of
clean up code before you terminate.
Jet 3.0 should not be so vulnerable to this as previous versions (2.x)
but is best to go by the book.
HTH
In some cases