Detect and trap network connection error on form

[Beth]

I have a form in an Access 2002 database that is running in Access Runtime.
The form is a student's record that links to the students table and has a
subform that links to the exams table with all their exams.
Both of those tables reside on a computer that is being accessed over a
network.
The problem I am now having is that while my end users are using the invoice
form I may have people on the main computer pulling the network cables or
even turning the computer off. Obviously, the end user is going to lose the
connection and any unsaved data on the form. However, Access is
experiencing a fatal error and the entire program closes.
I have tried all the error trapping I can think of to just alert the user to
the problem and return them to a form not linked to the datasource, but
nothing is working.

I would appreciate any suggestions for events to call, or code to put in
place to stop this problem.
thanks in advance.

Beth

 

[Albert D. Kallal]

You can't really drive a car down a road on broken glass and nails, and then
ask how to prevent a flat tire.

The solution in the above is to clean the road...or drive on a different
one.

A un-plugged network cable is a once a year occurrence, and it something you
really can't plan for.

Further, after a un-plugged cable, the back end data is likely going to be
damaged, or corrupted
and you will be forced to go the previous days backup. The current file will
often be
unusable after such a disconnect. I explain WHY this damage occurs here:

Please read CAREFULLY the following article, and pay SPECIAL attention
to the part of the article that talks about corruption of a data file.
( Why a does JET file share corrupt when the connection breaks?)

http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html

I have tried all the error trapping I can think of to just alert the user
to the problem and return them to a form not linked to the datasource, but
nothing is working.

You could try the forms error event, that should work, once
you split your database.

So, this "crash" will
likely go away if you setup your software correctly, so the next
question is the database split? You MUST split the database
in a multi-user environment. If you do this, then when the
network cable is pulled, you will find that ms-access does not
crash anymore. I explain WHY you must split not just
TELL you to spit here:

http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

If you database is not split, and the network cable is un-plugged,
then how can the error code run that is not available anymore since the
cable is un-plugged? How will ms-access run that error code when
the code is on the remote file share? This is ONE OF MANY
reasons why you need to split...

I would appreciate any suggestions for events to call, or code to put in
place to stop this problem.

You can't put your hand in a fire and not expect it to get burned. You
must find, and prevent those network disconnects from occurring
immediately, and if you don't, you will find your data file will
get damaged on a regular bases..and you have to go to the
previous days backup. (and, if you don't have backup system
in place, then your existing file may need to be sent to a place
to have the data recovered, as ms-access will NOT be able
to use the file anymore. So, good backup is another thing
to get up and running ASAP).

Splitting your database should fix the crash problem also.

If you database is already split, then try the forms "error" event.

 

[Beth]

Albert,
Thank you for the response and the suggestions.

The file is split into a front end/back end with the user interface having
tables that are linked to the backend. It has some of it's own independent
tables, but most of them are linked to the database on the remote computer.
The network connection going down is happening on a regular basis and I
can't prevent it. I know it is a bad situation and I have taken all the
actions I can to prevent the problem. Unfortunately, we have users on the
main computer that don't hesitate to turn it off, or remove it from the
network without notifying users. Since I am unable to do anything else to
prevent it, I am trying to minimize the problems on my end, where I can
control the scenario.

I tried the on error event for the form, but it never triggers.

I will see if there is anything else I can do to get the main users to leave
the computer and network alone.
Thanks,
Beth

 

[Albert D. Kallal]

Sounds like you have a difficult situation....this is unfortunate.

You really have to prevent those dis-connects, and you data is at risk if
you don't.

In act, you can't even be sure that a record will be saved correctly if you
have those
disconnects. It means you can't trust the data and numbers in your database.
It
might say the sales are one number, but in fact different. I guess it
supposes
how important the data is. If it is a Christmas party mailing list, then the
worst
problem is someone don't get invited. If it is sales numbers, invoicing, or
drug doses, then budgets, hiring decisions and or worse, how much
medicine to be adminsitred has much more serious consequences.

If you can't rely on the numbers produced in reports, then you
will have to decide how serious of matter this is, or perhaps it don't
matter one bit at all...

I tried the on error event for the form, but it never triggers.

Well, if there is particular piece of code that runs for the
update code, then make sure
that routine has error code in it. (simply be more aggressive
and place error code in all of the forms routines. That
error code may very will prevent the crash.
However, if you have error code
in those routines already...then there is likely
not much you can do here, but simply prevent
the disconnects.