Decompiling

[Guest]

My Access 2000 db gets corrupted every now and then, maybe once a week. I
track all logins to the db so I have been able to isolate the two problem
users. It is most likely related to their pc's poor network connectivity.
My db is about 15MB.

In order to repair the db, I must first use the "/decompile" switch, then
compile the code, then Compact/Repair. This works all the time. However,
performing only a Compact/Repair doesn't repair the database for some reason.

Should I be concerned about this? Is there some deep rooted problem I
should be looking for? Thx.

 

[Douglas J Steele]

Take a look at what MichKa has to say about this at
http://www.trigeminal.com/usenet/usenet004.asp and draw your own
conclusions.

If you're having to do this repeatedly, then I would say that there is some
deep rooted problem that you should be worried about. Take a look at what
Tony Toews has at http://www.granite.ab.ca/access/corruptmdbs.htm

 

[Mike Labosh]

My Access 2000 db gets corrupted every now and then, maybe once a week. I

track all logins to the db so I have been able to isolate the two problem
users. It is most likely related to their pc's poor network connectivity.
My db is about 15MB.

In order to repair the db, I must first use the "/decompile" switch, then
compile the code, then Compact/Repair. This works all the time. However,
performing only a Compact/Repair doesn't repair the database for some
reason.

Should I be concerned about this? Is there some deep rooted problem I
should be looking for? Thx.

At the company I work for...

On a network share, we have done this with Access 97 in ONE folder:

18.8 GB (20,219,521,251 bytes)

We have a single table called "Contacts" that is vertically split into
several mdb files that each contain only a 1 GB "Contacts" table with a
certain subset of the records, all of which are linked to a master database
where all the queries do a UNION across them. We have tables that are over
200 columns wide. We have update queries that invoke VBA code that runs
Update Queries that call other VBA code. We have found and successfully
worked around almost every single maximum limit that Access has.

(not that I like it)

A 15 MB database is child's play. More than 10 years ago, I was working in
Access 2.0 for WFW 3.1 on databases that were over 65 MB.

Do a repair first. Then a compact. Decompiling the code should be
irrelevant.

If a repair / compact doesn't fix it, then there are three possibilities:
1. The mdb is hosed. Export your data to a new fresh empty mdb.
2. Access is hosed. Uninstall it and Reinstall it.
3. Restore your last working backup from tape.
(You're doing this, right? RIGHT? [Insert Jedi Mind Trick Here:
BACKUP!])

 

[Tony Toews]

My Access 2000 db gets corrupted every now and then, maybe once a week. I
track all logins to the db so I have been able to isolate the two problem
users. It is most likely related to their pc's poor network connectivity.

Excellent. Glad you've isolated the problem to one particular
system.

In order to repair the db, I must first use the "/decompile" switch, then
compile the code, then Compact/Repair. This works all the time. However,
performing only a Compact/Repair doesn't repair the database for some reason.

But the MDB on the server shouldn't have any code thus it shouldn't
required any decompiling.

Have you split the MDB into a front end containing the queries, forms,
reports, macros and modules with just the tables and relationships?
The FE is copied to each network users computer. The FE MDB is
linked to the tables in the back end MDB which resides on a server.
You make updates to the FE MDB and distribute them to the users,
likely as an MDE.

See the "Splitting your app into a front end and back end Tips" page
at http://www.granite.ab.ca/access/splitapp/ for more info. See the
Auto FE Updater downloads page
http://www.granite.ab.ca/access/autofe.htm to make this relatively
painless.. The utility also supports Terminal Server/Citrix quite
nicely.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Guest]

Yeah. I realize your point about splitting the db. Initially the scope of
this project was for just a few users, plus when I tested the FE/BE approach,
the database slowed down noticably, so I decided not to split. However, not
even a year has passed and the scope has expanded and the #of users has
quadrupled!

I will have to split the db now and see if those links have any performance
tips for split databases. Thanks.

 

[Tony Toews]

Yeah. I realize your point about splitting the db. Initially the scope of
this project was for just a few users, plus when I tested the FE/BE approach,
the database slowed down noticably, so I decided not to split. However, not
even a year has passed and the scope has expanded and the #of users has
quadrupled!

Good job on getting more users on the system.

I will have to split the db now and see if those links have any performance
tips for split databases. Thanks.

For more information visit my Access Performance FAQ page at
http://www.granite.ab.ca/access/performancefaq.htm

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm