Corrupted back end corrputs all front ends! 
Author Message
 Corrupted back end corrputs all front ends!

I have a frontend/backend application with the backend residing on an NT
server and around 10 Win98 clients.

I have lived the following horror scenario three times so far:

A serious system crash on one of the clients leads to the backend db getting
corrupted. The other users logged in at that time do not notice anything at
first, but trying to log in again yields the error "Unrecognized database
format..." (it's normally the user that crashed who gets it first when he
restarts the front end application after rebooting). So I tell everyone to
log out, manually open the backend db, Access tells me that it has to repair
the database and so far has always succeeded in doing so. But NOW the absurd
happens. The users who were logged on at the time of the crash experience
the strangest errors after logging back in:
Some get runtime errors right in the startup routines (like "this field is
to small for the data you are trying to insert" in a simple OpenRecordset
call), on other machines certain subforms do not load and stay blank, and
the worst is that some appear to start normally, but a close look reveals
that they display absurd data mixed from several records or entirely random
(like an 1899 date which I know does not exist in any field of my whole
database).
A compact/repair on each of the frontends returns things to normal. I can
think of ways to handle the whole thing programmatically (and I will have to
do so), including forcing the individual front ends to compact/repair on
startup after being forcefully logged out, but I find it very very
troublesome - especially the case in which things appear normal.
To me it seems like a serious bug in Access which allows it to entirely
corrupt a front end application simply by accessing corrupted backend data!

Has anyone seen somthing similar?

Rupert

P.S.: I hoped that mde's might be immune to getting corrupted but they're
not.



Tue, 16 Jul 2002 03:00:00 GMT  
 Corrupted back end corrputs all front ends!
Rupert,

I've seen this happen occasionally with A97.  In my case, the backend wasn't
corrupted, just compacted as part of routine maintenance.  Following this,
opening most tables/queries (in datasheet view, a recordset, a form, or a
report) showed the fields offset by one (to the right, iirc).  This is most
obvious if you open a table directly in datasheet view from a frontend, in
which case you might see something like the following:

FirstName    LastName    Telephone    ...
-----------    ----------    -----------
(null)            John             Doe

This sort of thing would account for all the problems you described
following the compact/repair of the backend.

As for how to deal with it, the only means I know is to use a freshly
compacted copy of the frontend.  However, this doesn't require compacting
the frontend on every workstation--replacing the frontend with a compacted
copy works just fine.  Granted, even this can be a hassle if you don't plan
for it in advance.  Here's how I handle it:

1.  Every time I upgrade the frontend (freshly compacted for distribution),
I create a self-extracting zip archive for its distribution.  The default
path for extraction of the zipped files is the same as the default path for
installation of the original frontend, so most (if not all) users won't have
to do anything but run the extraction.
2.  The self-extracting archive always gets placed on the same path on the
same server, so I can simply equip each user with a desktop shortcut to the
file.  Since the most recent version is always available at this path, they
are safe running the "upgrade" at any time.
3.  Although the main purpose of the zip archive was originally to allow the
users to upgrade the application themselves, I've also told them that the
first thing they should do when the receive an "unusual" error in the
frontend is to close the app, run the upgrade, reopen the app, then try the
same operation again.  If they don't have any problems after this, they
don't even need to bother calling me.

This approach has put a major dent in the number of support calls I receive,
particularly since most of the "flaky" errors that I handled previously were
actually due to minor corruption of the frontend or some Access or DLL
internal error that is best circumvented by simply closing and reopening the
application.  It also means that I can simply instruct the users to follow a
well-known procedure if I happen to be the first person to detect "field
drift" following compacting of the backend.

HTH,
Nicole


Quote:
> I have a frontend/backend application with the backend residing on an NT
> server and around 10 Win98 clients.

> I have lived the following horror scenario three times so far:

> A serious system crash on one of the clients leads to the backend db
getting
> corrupted. The other users logged in at that time do not notice anything
at
> first, but trying to log in again yields the error "Unrecognized database
> format..." (it's normally the user that crashed who gets it first when he
> restarts the front end application after rebooting). So I tell everyone to
> log out, manually open the backend db, Access tells me that it has to
repair
> the database and so far has always succeeded in doing so. But NOW the
absurd
> happens. The users who were logged on at the time of the crash experience
> the strangest errors after logging back in:
> Some get runtime errors right in the startup routines (like "this field is
> to small for the data you are trying to insert" in a simple OpenRecordset
> call), on other machines certain subforms do not load and stay blank, and
> the worst is that some appear to start normally, but a close look reveals
> that they display absurd data mixed from several records or entirely
random
> (like an 1899 date which I know does not exist in any field of my whole
> database).
> A compact/repair on each of the frontends returns things to normal. I can
> think of ways to handle the whole thing programmatically (and I will have
to
> do so), including forcing the individual front ends to compact/repair on
> startup after being forcefully logged out, but I find it very very
> troublesome - especially the case in which things appear normal.
> To me it seems like a serious bug in Access which allows it to entirely
> corrupt a front end application simply by accessing corrupted backend
data!

> Has anyone seen somthing similar?

> Rupert

> P.S.: I hoped that mde's might be immune to getting corrupted but they're
> not.



Tue, 16 Jul 2002 03:00:00 GMT  
 Corrupted back end corrputs all front ends!
According to microsoft, you should renew all links after making changes
to the backend tables (fields, indexes etc).
In fact, this is seldom necessary.

I infer that the front end tries to refresh the link properties if the back
end changes, but that the process has bugs and is prone to errors

In your case it appears that the front end has tried to adjust to a back
end change - but has not correctly adjusted back when the back end
is fixed.

Quote:

>I have a frontend/backend application with the backend residing on an NT
>server and around 10 Win98 clients.

>I have lived the following horror scenario three times so far:

>A serious system crash on one of the clients leads to the backend db
getting
>corrupted. The other users logged in at that time do not notice anything at
>first, but trying to log in again yields the error "Unrecognized database
>format..." (it's normally the user that crashed who gets it first when he
>restarts the front end application after rebooting). So I tell everyone to
>log out, manually open the backend db, Access tells me that it has to
repair
>the database and so far has always succeeded in doing so. But NOW the
absurd
>happens. The users who were logged on at the time of the crash experience
>the strangest errors after logging back in:
>Some get runtime errors right in the startup routines (like "this field is
>to small for the data you are trying to insert" in a simple OpenRecordset
>call), on other machines certain subforms do not load and stay blank, and
>the worst is that some appear to start normally, but a close look reveals
>that they display absurd data mixed from several records or entirely random
>(like an 1899 date which I know does not exist in any field of my whole
>database).
>A compact/repair on each of the frontends returns things to normal. I can
>think of ways to handle the whole thing programmatically (and I will have
to
>do so), including forcing the individual front ends to compact/repair on
>startup after being forcefully logged out, but I find it very very
>troublesome - especially the case in which things appear normal.
>To me it seems like a serious bug in Access which allows it to entirely
>corrupt a front end application simply by accessing corrupted backend data!

>Has anyone seen somthing similar?

>Rupert

>P.S.: I hoped that mde's might be immune to getting corrupted but they're
>not.



Wed, 17 Jul 2002 03:00:00 GMT  
 Corrupted back end corrputs all front ends!
Thanks a lot Nicole for your explanation and exhaustive comments - heaven
must have sent you!



Quote:
> Rupert,

> I've seen this happen occasionally with A97.  In my case, the backend
wasn't
> corrupted, just compacted as part of routine maintenance.  Following this,
> opening most tables/queries (in datasheet view, a recordset, a form, or a
> report) showed the fields offset by one (to the right, iirc).  This is
most
> obvious if you open a table directly in datasheet view from a frontend, in
> which case you might see something like the following:

> FirstName    LastName    Telephone    ...
> -----------    ----------    -----------
> (null)            John             Doe

> This sort of thing would account for all the problems you described
> following the compact/repair of the backend.

> As for how to deal with it, the only means I know is to use a freshly
> compacted copy of the frontend.  However, this doesn't require compacting
> the frontend on every workstation--replacing the frontend with a compacted
> copy works just fine.  Granted, even this can be a hassle if you don't
plan
> for it in advance.  Here's how I handle it:

> 1.  Every time I upgrade the frontend (freshly compacted for
distribution),
> I create a self-extracting zip archive for its distribution.  The default
> path for extraction of the zipped files is the same as the default path
for
> installation of the original frontend, so most (if not all) users won't
have
> to do anything but run the extraction.
> 2.  The self-extracting archive always gets placed on the same path on the
> same server, so I can simply equip each user with a desktop shortcut to
the
> file.  Since the most recent version is always available at this path,
they
> are safe running the "upgrade" at any time.
> 3.  Although the main purpose of the zip archive was originally to allow
the
> users to upgrade the application themselves, I've also told them that the
> first thing they should do when the receive an "unusual" error in the
> frontend is to close the app, run the upgrade, reopen the app, then try
the
> same operation again.  If they don't have any problems after this, they
> don't even need to bother calling me.

> This approach has put a major dent in the number of support calls I
receive,
> particularly since most of the "flaky" errors that I handled previously
were
> actually due to minor corruption of the frontend or some Access or DLL
> internal error that is best circumvented by simply closing and reopening
the
> application.  It also means that I can simply instruct the users to follow
a
> well-known procedure if I happen to be the first person to detect "field
> drift" following compacting of the backend.

> HTH,
> Nicole



> > I have a frontend/backend application with the backend residing on an NT
> > server and around 10 Win98 clients.

> > I have lived the following horror scenario three times so far:

> > A serious system crash on one of the clients leads to the backend db
> getting
> > corrupted. The other users logged in at that time do not notice anything
> at
> > first, but trying to log in again yields the error "Unrecognized
database
> > format..." (it's normally the user that crashed who gets it first when
he
> > restarts the front end application after rebooting). So I tell everyone
to
> > log out, manually open the backend db, Access tells me that it has to
> repair
> > the database and so far has always succeeded in doing so. But NOW the
> absurd
> > happens. The users who were logged on at the time of the crash
experience
> > the strangest errors after logging back in:
> > Some get runtime errors right in the startup routines (like "this field
is
> > to small for the data you are trying to insert" in a simple
OpenRecordset
> > call), on other machines certain subforms do not load and stay blank,
and
> > the worst is that some appear to start normally, but a close look
reveals
> > that they display absurd data mixed from several records or entirely
> random
> > (like an 1899 date which I know does not exist in any field of my whole
> > database).
> > A compact/repair on each of the frontends returns things to normal. I
can
> > think of ways to handle the whole thing programmatically (and I will
have
> to
> > do so), including forcing the individual front ends to compact/repair on
> > startup after being forcefully logged out, but I find it very very
> > troublesome - especially the case in which things appear normal.
> > To me it seems like a serious bug in Access which allows it to entirely
> > corrupt a front end application simply by accessing corrupted backend
> data!

> > Has anyone seen somthing similar?

> > Rupert

> > P.S.: I hoped that mde's might be immune to getting corrupted but
they're
> > not.



Sun, 21 Jul 2002 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. A2k: Controlling a back-end MDB from its FRONT-end MDB

2. A2K Updating Back End with new fields from Front End

3. Compact the back-end data from the front-end

4. Splitting db in front end and back end

5. Compact back-end front-end

6. Trying to Create a communicator for VB.net Front End and SQL 2000 back end

7. VB Front end dll loses connection to back end SQL server db after an hour

8. Front-End & Back-End

9. Packaging a VB front end/Access back end application

10. Access Back End, VB Front End -- Why?

11. Access Back End, VB Front End -- Why?

12. App Security - front-end or back-end?

 

 
Powered by phpBB® Forum Software