racking / Logging User(s) Who Crashed Database

[Guest]

First, I would like to thank everyone in advance for all their posts
previously; I've found numerous tips and explanations that has vastly helped
me and my database. Thanks so much!

Secondly, please accept my apologies if I posted this message in the wrong
thread; I wasn't sure where the best place to post it so I opted for the best
one - General.


What I'd like to accomplish, and I couldn't find anything in regards to this
after a few hours of searching through here, is how to track the user(s) who
do not exit properly and crashes the database (I get the error that states
the database needs to be repaired and that it was most likely from a user who
exited illegally.)

I can't tell you how many times I've gone to each user and spent time
explaining how to close out properly (each form has a return to previous menu
button, and a close application button) but someone, or some people, are just
not caring what they're doing (thinking they can get away with it) and I'm
constantly having to back up the database and repairing it. I always do the
backup at least twice a day; I don't have a problem with it, but it's doing
it six times a day because someone keeps exiting improperly that is driving
me insane.

I am almost 100% sure there's a way to do this - Any help, point in the
right direction, anything, I would most definitely be grateful for!!!

BTW - This is not a front-end, back-end database (I haven't learned all
about those yet....) and the database is on a shared network.

 

['69 Camaro]

Hi.

BTW - This is not a front-end, back-end database (I haven't learned all
about those yet....) and the database is on a shared network.

Here's your problem. The Microsoft Access development team has identified
sharing a multiuser database across the network as the number one cause of
database corruption. Split your database into a front end (forms, queries,
modules, et cetera) and back end (tables and relationships), then place the
back end on the shared networked server and a copy of the front end
distributed to each user's workstation, and you'll breathe a lot easier.

For more information on split databases, please see the following Web page:

http://www.Access.QBuilt.com/html/gem_tips1.html

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

 

[John W. Vinson]

On Sun, 28 Oct 2007 11:20:00 -0700, Vylent Fyre

Racking the users might violate various state and federal laws; flogging is an
alternative but it also has problems.

BTW - This is not a front-end, back-end database (I haven't learned all
about those yet....) and the database is on a shared network.

Splitting your database is going to be much more beneficial for employee
morale, as well as for the well-being of your database.

John W. Vinson [MVP]

 

[Tony Toews [MVP]]

BTW - This is not a front-end, back-end database (I haven't learned all
about those yet....) and the database is on a shared network.

1) As Gunny states, you really, really want to split the database. A
link to a page n my website with some additional information and a
helpful utility.

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.

2) I created the following web page Tracking users entering and
exiting Microsoft Access Front End
http://www.granite.ab.ca/access/tracking_users_entering_and_exit.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
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[George Nicholson]

BTW - This is not a front-end, back-end database (I haven't learned all

about those yet....) and the database is on a shared network.

Change that ASAP. Access files are not intended to be used by multiple
people simultaneously unless they have been properly set up as front end &
backend files. The fact that your database is being used in a manner never
intended (and specifically warned against) is the most likely cause of the
file corruption, not the action of any specific user.

AFTER that is done, you could add a "usage log" to your backend and capture
the networkID and timestamp of every login and logout (capturing the logout
is a little tricky, but only a little). If you still have corruption
problems once your db is split you can look at this file and look for users
who logged in but not out. Those people either exited improperly (using
CTRL-ALT-DELETE) or were logged in when their app (or machine) crashed,
thereby narrowing down your list of "suspects". I actually used this method
once to identify a "bad user" that seemed to be the cause of a corrupted
file. When approached, the user told me when he entered some very specific
values into a form, the app hung and he had no choice but to use TaskManager
to shut down the app. I tested the values and sure enough the app entered an
endless loop I would never have expected. So the "bad user" actually did
nothing wrong and ended up helping me fix a major bug.

HTH,

 

[David W. Fenton]

Access files are not intended to be used by multiple
people simultaneously unless they have been properly set up as
front end & backend files.

More specifically:

Access objects do not share well.

Jet objects share quite well.

That means:

Share:
tables
queries

Do not share:
forms
reports
macros
modules

On a practical basis, this means your back end has tables, and your
front end everything else.

 

[Guest]

Thank you for your response!

I think my biggest concern, aside from my ignorance on the FE and BE
situation, is the fact that I have so many users across the country that
access this database. How am I going to get a copy of the FE database on
everyone's personal computer? The database is already approaching 1 gig; I'm
sure it'll drop dramatically once I split it, though.

I need to take all these notes home and go through it to make sure I
understand BE and FE 100% - Ignorance produces even more complications

Thanks again!!

 

['69 Camaro]

Hi.

I have so many users across the country that
access this database. .. . .
The database is already approaching 1 gig

A 1 GB Access database on a WAN?!!! Oooooh, the pain . . . .

How am I going to get a copy of the FE database on
everyone's personal computer?

Use Access MVP Tony Toews's free AutoFE utility to automatically replace
updated front ends on the user's hard drive whenever the user opens the
database file. Please see the following Web page:

http://www.granite.ab.ca/access/autofe.htm

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

 

[John W. Vinson]

I think my biggest concern, aside from my ignorance on the FE and BE
situation, is the fact that I have so many users across the country that
access this database.

YIPE!!!!

Stop. Do not pass GO, do not collect vast numbers of database corruptions.

Access is a wonderful program, and it *can* be used over a WAN (wide area
network) - but it cannot be used safely or reliably over a WAN. It's just not
designed for it. Using a single unitary database remotely is dangerous; using
a split database with a frontend in Boston and a backend in Dallas (or
equivalent) is *even worse*.

You should very seriously consider using another option:

- a terminal server approach, with the backend and multiple frontends on the
same machine (or the same fast stable LAN); users would connect to the machine
using Windows Terminal Server, Citrix, or similar.
- A SQL/Server backend with ODBC connections from the users' machines. This
may require some redesign.
- A web solution (with a SQL, MySQL, or other client-server database and a
webpage programmed to interact with it).

What you're doing is the source of your frequent corruptions, and is asking
for trouble!

John W. Vinson [MVP]

 

[George Nicholson]

Total agreement.

Addition:
(As I understand it) Even though queries do "share well", they are
customarily placed in the front end because (once you've set up local front
ends and a shared network backend), that's the location that makes the most
(only?) sense from a network bandwidth persepective.


HTH,