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

Preventing Access from crashing, when it looses connection to the database

P: n/a
Hi all,

I have a split database. Both the forms, and the tables are stored on
a shared network drive (this is Access 2003).

The users use the forms, and the tables on the network drive, there
are no local copies.

When connection to this drive is lost, Access CRASHES. It does it
every single time. Does anyone know if there is a way to check if
connection to the file has been lost, or do something to make this
experience less painful for the user?

Thanks,
Mark

Jun 18 '07 #1
Share this Question
Share on Google+
8 Replies


P: n/a
mark_aok wrote:
Hi all,

I have a split database. Both the forms, and the tables are stored on
a shared network drive (this is Access 2003).

The users use the forms, and the tables on the network drive, there
are no local copies.

When connection to this drive is lost, Access CRASHES. It does it
every single time. Does anyone know if there is a way to check if
connection to the file has been lost, or do something to make this
experience less painful for the user?

Thanks,
Mark
Fix your network.
Jun 18 '07 #2

P: n/a
What do you mean by Access crashes? How do you know that the connection is
lost? What message, if any, does a user see when Access crashes? Does
Access close on the users computer or does it freeze?
Lost connections to a netwrok drive is an IT issue and that group should look
into this if it happens often
Your description of the database does not indicate that it is split if all
users use the network db. A truly split databse has the tables in the
backend on a network drive and tables (linked to the backend), queries, forms,
tables, macros, and modules in the frontend on the users computer. As a
general "rule", only tables should be in the backend.
That they are all using the same db could be your problem.

mark_aok wrote:
>Hi all,

I have a split database. Both the forms, and the tables are stored on
a shared network drive (this is Access 2003).

The users use the forms, and the tables on the network drive, there
are no local copies.

When connection to this drive is lost, Access CRASHES. It does it
every single time. Does anyone know if there is a way to check if
connection to the file has been lost, or do something to make this
experience less painful for the user?

Thanks,
Mark
--
Message posted via http://www.accessmonster.com

Jun 18 '07 #3

P: n/a

"mark_aok" <ma******@hotmail.comwrote in message
news:11**********************@m36g2000hse.googlegr oups.com...
Hi all,

I have a split database. Both the forms, and the tables are stored on
a shared network drive (this is Access 2003).

The users use the forms, and the tables on the network drive, there
are no local copies.

When connection to this drive is lost, Access CRASHES. It does it
every single time. Does anyone know if there is a way to check if
connection to the file has been lost, or do something to make this
experience less painful for the user?

Thanks,
Mark
I would agree with the 1st post, fix your network.

To stop the lockups, move your front end db to the local drives as
recommended by MS. Other then corruption of the back end db and good error
checking in you VBA code, the front end should not lock up with the loss of
the network connection.
Jun 18 '07 #4

P: n/a
Access gives the following error message,
"Run-time error - 2147217865
The Microsoft Jet database engine cannot find the input table or query
'group'. Make sure it exists and that its name is spelled correctly"

Then (depending on what is happening when the network connection is
lost), Access completely dies (it completely shuts down, and asks if
you would like to send Microsoft an error report"

To clarify, I am on a stable network, and the odds of my network
crashing will not happen very often. But I just want to avoid Access
completely closing, and would like to know if it is possible to find
an onLostConnection, or some event that will allow me to make the
experience less painfull for the user.

Thanks for all the replies so far,

Mark



On Jun 18, 12:00 pm, "jahoobob via AccessMonster.com" <u12179@uwe>
wrote:
What do you mean by Access crashes? How do you know that the connection is
lost? What message, if any, does a user see when Access crashes? Does
Access close on the users computer or does it freeze?
Lost connections to a netwrok drive is an IT issue and that group should look
into this if it happens often
Your description of the database does not indicate that it is split if all
users use the network db. A truly split databse has the tables in the
backend on a network drive and tables (linked to the backend), queries, forms,
tables, macros, and modules in the frontend on the users computer. As a
general "rule", only tables should be in the backend.
That they are all using the same db could be your problem.

mark_aok wrote:
Hi all,
I have a split database. Both the forms, and the tables are stored on
a shared network drive (this is Access 2003).
The users use the forms, and the tables on the network drive, there
are no local copies.
When connection to this drive is lost, Access CRASHES. It does it
every single time. Does anyone know if there is a way to check if
connection to the file has been lost, or do something to make this
experience less painful for the user?
Thanks,
Mark

--
Message posted viahttp://www.accessmonster.com

Jun 18 '07 #5

P: n/a
One more thing. Why would it make sense to keep a copy of the forms
on people's PC's?? Wouldn't that just complicate things? I have 5
users using this database, and 99.9% of the time, it is just one user
at a time...

Mark

On Jun 18, 12:00 pm, "jahoobob via AccessMonster.com" <u12179@uwe>
wrote:
What do you mean by Access crashes? How do you know that the connection is
lost? What message, if any, does a user see when Access crashes? Does
Access close on the users computer or does it freeze?
Lost connections to a netwrok drive is an IT issue and that group should look
into this if it happens often
Your description of the database does not indicate that it is split if all
users use the network db. A truly split databse has the tables in the
backend on a network drive and tables (linked to the backend), queries, forms,
tables, macros, and modules in the frontend on the users computer. As a
general "rule", only tables should be in the backend.
That they are all using the same db could be your problem.

mark_aok wrote:
Hi all,
I have a split database. Both the forms, and the tables are stored on
a shared network drive (this is Access 2003).
The users use the forms, and the tables on the network drive, there
are no local copies.
When connection to this drive is lost, Access CRASHES. It does it
every single time. Does anyone know if there is a way to check if
connection to the file has been lost, or do something to make this
experience less painful for the user?
Thanks,
Mark

--
Message posted viahttp://www.accessmonster.com

Jun 18 '07 #6

P: n/a

"mark_aok" <ma******@hotmail.comwrote in message
news:11**********************@n60g2000hse.googlegr oups.com...
One more thing. Why would it make sense to keep a copy of the forms
on people's PC's?? Wouldn't that just complicate things? I have 5
users using this database, and 99.9% of the time, it is just one user
at a time...

Mark
Read my article as to why you don' want to do this:

http://www.members.shaw.ca/AlbertKal...plit/index.htm
Furthest, ask your IT people why for the least 20+ years, they always
installed every other piece of software on each computer..but all sudden
break with tradition here?

Further, READ VERY carefully the part above as to why you can't have a loss
of connection, else you likely to blow out your data file and have to go to
the previous days backup.

Further, keep in mind that breaking a connection to software that being run
"over" the network is going to be VERY MUCH more unstable, as parts of code,
or a form that requests other code and forms will most certainly crash when
the requested bits and pieces fail due to a loss of network.

How can you even have error code run when the connection breaks, and you
can't load that error code!! (do think about this for a second!!! If you
trap the error or loss of connection, then how will that error code load).

So, if you place your software on EACH workstation, you will find ms-access
to be much more stable. And, if you do put in some error trapping code, at
least the code can load and run because it on the workstation!! How can some
access code load and run error code when it is not your pc, and the
connection is broken? I not sure I really need to point this obvious
problem? In effect, this is not really a access issue or question, but
simply that of how can you load and run something when you don't have a
connection to what your trying to load and run!!!

So, think about how your IT been installing all software on each computer
for many many years now. Then all of a sudden, your code and applications
are NOT to installed on the workstation?

Anyway...read the above article, and perhaps give a copy to the IT people. I
sure once your IT people grasp the difference between data and an
application that runs code, then they will instantly see my point.

If your IT people can't tell the difference between data and code, then I
think we in trouble from the get go....

ms-access does not load everything into memory when it runs......

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
Jun 18 '07 #7

P: n/a
Thanks a lot for the information Albert.

Alright, it makes sense to keep the forms on people's individual
computers. But I had one final question. Your article mentioned
keeping connections to tables open at all times...this seemed
confusing.

My connections to tables currently go like this...
-Open a connection
-Edit Data
-Update
-Close connection

Or

-Open Connection
-Read data
-Close Connect

Are you suggesting that people remove all .close statements from there
code? I just found that part a little bit confusing.

Thanks,

BTW the article was very, very helpfull.

Mark

On Jun 18, 2:59 pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal...@msn.com>
wrote:
"mark_aok" <mark_...@hotmail.comwrote in message

news:11**********************@n60g2000hse.googlegr oups.com...
One more thing. Why would it make sense to keep a copy of the forms
on people's PC's?? Wouldn't that just complicate things? I have 5
users using this database, and 99.9% of the time, it is just one user
at a time...
Mark

Read my article as to why you don' want to do this:

http://www.members.shaw.ca/AlbertKal...plit/index.htm

Furthest, ask your IT people why for the least 20+ years, they always
installed every other piece of software on each computer..but all sudden
break with tradition here?

Further, READ VERY carefully the part above as to why you can't have a loss
of connection, else you likely to blow out your data file and have to go to
the previous days backup.

Further, keep in mind that breaking a connection to software that being run
"over" the network is going to be VERY MUCH more unstable, as parts of code,
or a form that requests other code and forms will most certainly crash when
the requested bits and pieces fail due to a loss of network.

How can you even have error code run when the connection breaks, and you
can't load that error code!! (do think about this for a second!!! If you
trap the error or loss of connection, then how will that error code load).

So, if you place your software on EACH workstation, you will find ms-access
to be much more stable. And, if you do put in some error trapping code, at
least the code can load and run because it on the workstation!! How can some
access code load and run error code when it is not your pc, and the
connection is broken? I not sure I really need to point this obvious
problem? In effect, this is not really a access issue or question, but
simply that of how can you load and run something when you don't have a
connection to what your trying to load and run!!!

So, think about how your IT been installing all software on each computer
for many many years now. Then all of a sudden, your code and applications
are NOT to installed on the workstation?

Anyway...read the above article, and perhaps give a copy to the IT people. I
sure once your IT people grasp the difference between data and an
application that runs code, then they will instantly see my point.

If your IT people can't tell the difference between data and code, then I
think we in trouble from the get go....

ms-access does not load everything into memory when it runs......

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKal...@msn.com

Jun 18 '07 #8

P: n/a
Alright, it makes sense to keep the forms on people's individual
computers. But I had one final question. Your article mentioned
keeping connections to tables open at all times...this seemed
confusing.
No, it says connection (singular). That suggestion is to simply keep (force)
the front end program to keep the connection open at all times. This can be
any table you choose. You do NOT have to do this on a table by by table
approach here.

so, just pick any old table, and keep it open. There is no special
suggestion or particular table that you need to keep open here. However,
when ms-access opens a table, if there is no connection to the back end (via
any table), then the locking file, and whole rather complex process has to
occur..this can cause rather large delays in form opens etc.
>Are you suggesting that people remove all .close statements from there
code? I just found that part a little bit confusing.

No, I simply saying that we want the process of the front end making a
connection to the back end to occur only once. Keeping any old table open
will accomplish this. Sometimes you not notice a change in performance, in
some cases however it is dramatic... especially when you have to open, and
close a bunch of recordsets....
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
Jun 18 '07 #9

This discussion thread is closed

Replies have been disabled for this discussion.