Unintended modification of VBA code behind Access form

[Conrad Carlberg]

I have a fairly complex Access 97 database on a network share folder that is
opened by network users roughly 125 times per day. It's a front-end/back-end
database. The back-end is weakly password protected. The front-end is
protected by a combination of disabling Shift key bypass and a check of the
username. The reason that we have not implemented workgroup protection is
that the company's IS (yes, they still call themselves IS) department is not
up to dealing with that and I'm not there all the time.

The database has been in place, largely in its present form, for about five
years. It contains a roster of doctors at a hospital. When the user opens
it, a form is displayed via the Tools | Startup options. There are several
dropdowns that the user can employ to select either one particular doctor or
a subset of doctors, by specialty, for example, or by medical group or by a
couple of other criteria. The various Startup options are set to prevent a
user from getting his grubby little fingers on the form design and the VBA
code behind the form.

About a week ago, we found that a period had somehow been inserted into the
After Update event for one of the dropdowns in the front-end. The period
caused a compile error when the user employed the dropdown. I was really
puzzled because I believed the front-end to have been buttoned down pretty
tight. To get at the code, a malicious user would have had to learn my user
password. He would also have to go through Auto Keys combinations to enable
the Shift key bypass. This implies some hostility, determination and
expertise -- unlikely but not impossible.

We removed the period from the code and all was well. Two days later, the
period appeared again, in the same place it had before! I don't think this
has been caused by human intervention, although I could be wrong. I think
it's something systemic. Tracking indicates that the file was _not_ restored
from a tape backup. Has anyone seen anything similar to this?

 

[Albert D.Kallal]

Well, two things:

You got a split system, but do you place the front end on EACH pc??

2nd

Why are you not using a mde here? They are more reliable?

There is simply no excuse for the above. Please read the following of mine
on why you split, and more importantly WHY YOU place a mde on EACH pc.

 

[Douglas J Steele]

I've never heard of this, but why not distribute the front-end as an MDE so
that the VBA cannot be altered?

 

[Albert D.Kallal]

opps....

here is the link:

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

 

[Conrad Carlberg]

Thanks, Doug. I intend to. Nothing like this has happened before now to this
database, so there was no special reason to do so, but now there may be.
Meantime, I'm hoping to hear that this can occur systemically, so that we
aren't forced into accepting the notion that a user has gone malicious on
us. And if it is a systemic problem, is it clear that an MDE can prevent it
from recurring?

 

[Douglas J Steele]

Since I've never heard of the problem occurring before, I'm hard pressed to
be able to guarantee an MDE will prevent it from recurring <g>, however,
since the VBA code is stripped out of an MDE (or, more accurately, only
there in a tokenized version), there really isn't any way that the same sort
of problem could occur.