Max Concurrent Users on .MDB running hidden in the background

[Steve]

I have a .mdb that I use as a sort of time keeper in my office. It opens
automatically when the user signs in and closes when they log off. The only
thing the db does right now is, when the form opens, it records the logon
time from windows and puts it into a table. And when the form closes
(computer is shut down), it records the time and enters it into a table.
That's all it does. Two events and two append queries per person per day. The
max number of people that will have it "open" at one time is 19, but 80% of
the time only 6 to 10 will have it open. I've been using it for several weeks
this way without a hitch. I guess the relatively low activity of only two
append queries isn't causing a problem. It is not split since there is no
interaction by anyone with it. The only thing that is needed is to open a
form at the beginning of the shift and close the form at the end of the shift
(again, both are done automatically behind the scenes and the user never
interacts with the mdb or even knows it's there).

Here's my question: I am considering having the .mdb also record other
information every minute using the forms OnTimer event. So, every minute, a
procedure will fire and append a new line to a table. I am going to set it up
so I can turn it off and on by person, so I can have as many or as few as I
want having this extra function running as I want. How many people can I
reliably have this extra function running on at one time given what I
described above? I can also have this function run and append the record into
another db that is used less frequently, but I have to run the code in this
db that runs in the background on everyone. Would it be better to insert the
record into the other db that is used much less frequently? I would like to
run this extra operation on everyone at the same time if I can, but if I have
to run it on only a few at a time, I can do that to.

Thanks
Steve

 

[Douglas J. Steele]

You say "It is not split since there is no interaction by anyone with it.",
but that's not a valid reason not to split it.

Multiple users sharing a single application is a sure recipe for disaster.

 

[Steve]

Ok. I didn't think it was necessary as there are no queries or actions going
on other than the two append queries per person. I was thinking I may need to
split it to perform the new functions that I want done. But still, splitting
it and appending to the current tables or appending to tables in another db
that gets little action... which would be best for my situation and how many
people can I safely run the ontimer event every minute?

 

[Douglas J. Steele]

If you split the application, so that each user has his/her own copy of the
front-end, how many people can safely run the ontimer event every minute
should become irrelevant, since each user's application would be independent
of all other users.(For that matter, there's really no reason why the
front-end needs to be in Access: a VB program might actually be better
suited in this case)

 

[Tony Toews [MVP]]

You say "It is not split since there is no interaction by anyone with it.",
but that's not a valid reason not to split it.

Multiple users sharing a single application is a sure recipe for disaster.

Actually he might be ok. The problems that occur seem to be when
filters on forms get updated and Access wants to save the form. Or
similar types of things happening to forms and report objects.

If all he is doing is running a bit of code on a timer from a single
code with some append queries he might not have any problems.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/

 

[Steve]

I'll go ahead and split it to be safe. I had a vague understanding of why a
database should be split. I read some of the other posts and websites that
people on this board have referred to and it really filled me in on why a db
should be split when it starts getting used more heavily.