By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,389 Members | 2,070 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,389 IT Pros & Developers. It's quick & easy.

Automation Error: Catstrophic Failure [Long]

P: n/a
Our Access 97 database is a single-file (non-splitted, pure Access)
hosted no a network server, accessed regularly by a handful of users
around the office.

Until recently (until the Great Blackout, actually), there have been
no problem with the database. It seems to handle simultaneous users
fine and did not cause any grief. The blackout corrupted the DB, but
we restored a pre-blackout version, so everything was good for a
while.

We did notice though, that ever since the black out, the database has
been experiencing various problems. Usually little things that
Compact / Repair would fix, but every now and then, we would have
unfixably corrupted forms / reports, and we would have to import
working versions of them from an older backup in a blank database.

Just recently, we experienced the weirdest problem yet. The users
were chugging along nicely when all of a sudden, they would boot up
the DB and be confronted with an "Compile Error: Automation Error".
The code would break in the Switchboard, on the line "Dim dbs As
Database". Several forms / reports would also not function when
opened manually from the DB window.

I did some searching on this, and found some instances where broken
references were the cause of grief, so I checked Tool --> References,
but everything seemed okay: the usual 3 libraries were checked off,
and the DLL files seem to be present and accounted for.

Now here is the great part, I try importing all the objects into a
blank database, and when I reach certain items, I get the scariest
error I've seen as a young programmer: "Automation Error: Catastrophic
Error"! A form and a report also fail to import with "Unexpected
Error (35012)". Funny enough, the swithboard imported and functions
without problems.

Does anyone know what is wrong with my database? Would splitting the
database alleviate these issues? Why does the database have problems
all of a sudden?

Thank you for taking your time and reading this monstrous post. I'm
rather rattled by this. Any comments / suggestions would be greatly
appreciated.
Nov 12 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Not a "monstrous" post at all! Everything you say is relevent & to the
point.

As others will doubtless confirm, splitting the database is good for many
reasons. I think that reducing corruption, is one of them. You have a single
BE db on the server, with all of the tables but none of the code, then a
seperate copy of the FE db on each user's PC, with all of the code, & links
to the tables in the BE db.

Facilitating code updates is another good reason for splitting the db. You
just copy the new FE db over each of the old ones. The data stays untouched
in the BE db.

You will find tons more info. on db splitting by searching google groups.

As for the automation errors, I'm not sure what they would be. If I were
you, I would repeat the "import into a new blank database" thing until
everything imported ok, with no errors at all. Then split *that* db, & take
it from there.

HTH,
TC
"Andante.in.Blue" <6p*******@sneakemail.com> wrote in message
news:a8**************************@posting.google.c om...
Our Access 97 database is a single-file (non-splitted, pure Access)
hosted no a network server, accessed regularly by a handful of users
around the office.

Until recently (until the Great Blackout, actually), there have been
no problem with the database. It seems to handle simultaneous users
fine and did not cause any grief. The blackout corrupted the DB, but
we restored a pre-blackout version, so everything was good for a
while.

We did notice though, that ever since the black out, the database has
been experiencing various problems. Usually little things that
Compact / Repair would fix, but every now and then, we would have
unfixably corrupted forms / reports, and we would have to import
working versions of them from an older backup in a blank database.

Just recently, we experienced the weirdest problem yet. The users
were chugging along nicely when all of a sudden, they would boot up
the DB and be confronted with an "Compile Error: Automation Error".
The code would break in the Switchboard, on the line "Dim dbs As
Database". Several forms / reports would also not function when
opened manually from the DB window.

I did some searching on this, and found some instances where broken
references were the cause of grief, so I checked Tool --> References,
but everything seemed okay: the usual 3 libraries were checked off,
and the DLL files seem to be present and accounted for.

Now here is the great part, I try importing all the objects into a
blank database, and when I reach certain items, I get the scariest
error I've seen as a young programmer: "Automation Error: Catastrophic
Error"! A form and a report also fail to import with "Unexpected
Error (35012)". Funny enough, the swithboard imported and functions
without problems.

Does anyone know what is wrong with my database? Would splitting the
database alleviate these issues? Why does the database have problems
all of a sudden?

Thank you for taking your time and reading this monstrous post. I'm
rather rattled by this. Any comments / suggestions would be greatly
appreciated.

Nov 12 '05 #2

P: n/a
Thanks cafe. I just split the database and reimported all the objects
into a refresh front end for further development; so far so good
*crosses fingers*

The thing I've noticed is that the FE ends up being relatively
small... only 2.6 MB on compact, compared to the 17MB of tables in the
BE. Now, if network problems conspired to the corrupt the DB, I would
think that the chances of corruption in a table would be greater than
corruption of the forms. But -- quite fortunately -- we haven't
experienced any data lost yet (except perhaps a bit of code from an
irretrievable form). Now, I'm not complaining, mind you :) I'd much
rather rebuild a form than lose a table. I'm just wondering why this
is happening (so at least I can reassure myself that this won't happen
again).

Alan
Nov 12 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.