Trying to catch a bad user.

S

Scott Burke

I did not setup the existing software.
I have a user who has decided that she has the right to go into the program
code and write queries and run forms manually. She is causing problems! My
intension is to catch her doing what she is doing. Now the reasons for
catching her and not just stopping her are complex and I am sure none of you
won’t to hear about my office politics problems.

That said, here is what I won’t to do:
Every time someone holds the shift key and launches a program, I won’t to
log that event.
I really cant link a table in the program because she is likely to see it
and change the information in it. I wont this to be an under cover job.
Well, as long a possible.

Keep in mind that the person I am trying to catch has basic Access knowledge.

Ideals?

Scott Burke
 
S

Sreedhar

Hi Scott,

I wouldn't say its funny but interesting neverthless. Tell us more about how
your App is set up in your workplace.

For example, IMHO, if its a shared db with each client having their own FE,
then a single user wanting to query the data in a fashion that she deems fit
is not a big deal. But, creating their own input forms may increase the risk
of dangerous data creeping into the db. In any case, such a setup requires
the FE to be in mde file format, to prevent just those things.

Let's see who among the illustrious MVPs are ready to play Bond007. ;-)
 
J

John Nurick

Hi Scott,

I have a feeling that what you ask just ain't possible. The only way to get
Access to log something on startup is to run a macro or VBA code - and
holding the Shift key while launching the database prevents the startup code
from running.

One possibility is be to write code (in another mdb file) that uses DAO to
open the database and check the LastUpdated dates of the QueryDefs: running
this at intervals will show if someone has been mucking round with the
queries and when. Taking this a step further, you could have this code
obtain and store the SQL from the queries to get a further layer of
tracking.

If you also set up a scheduled task on the server that made a copy of the
ldb file at intervals you should be able to show that the queries were only
modified at times this user had the database open. (It may well be possible
to set up the server to log all accesses to the mdb file, which would be
even better.)

Ofer's answer covers most of the ways of *stopping* her modifying the
present database, but she would still be able to access the data from
another database or even another Office application. The next step would be
to implement user level security and RWOP queries to deny her any sort of
access except that "officially" provided for. The steps she'd have to take
to circumvent that would be a sacking offence in almost any organisation!

John
 
B

Brendan Reynolds

As John says elsewhere in this thread, it may not be possible to do this
from within your app, as the action you're trying to detect happens before
any code in your app has a chance to run. There are third-party tools
available to track activity. Check out the following list ...

http://www.google.com/search?q=keylogger

Careful who you buy from - if I was going to buy something like this, I'd
want to be sure that the vendor was an established and reputable company.
Otherwise, you might not be the only person logging those keystrokes!
 
S

Scott Burke

That was what I was afraid of.
When we were using Dbase/clipper code she was caught using the dbase editor
to make changes. Of course she did not see the need to attach the indexes
when she did this. Then she learned to attach indexes but did not understand
why you don’t use alpha char in a logical or date fields.

That is why I wonted to catch her. I won’t to prove to the boss/owner that
I am a competent programmer. The problems are being cause by person X who
just happens to have been with the company for 28 years.

I might have to use the key logger ideal.
Thank you for your time and input.

Scott Burke
 
J

John Nurick

Good suggestion - but implementing it could raise privacy and HR issues with
legal consequences.

Scott, if you think of going this way be sure to cover your back. E.g. make
sure that management (a) understand the privacy and other issues as they
apply in whatever jurisdiction you're in and (b) give you explicit written
instructions to install the key logger and use its results.
 
S

Sreedhar

Hi Scott,

Your thread interests me in that I faced a similar situation, though not
this intense, in my office. I simply switched back to "prevent" mode. You
have got the best of advice from better heads. Though, I would like to add my
two cents.

In an FE/BE setup, can you simply walkover to her machine and point out the
differences between the standard file and the one she uses ? Unless she is
smart enough to delete all the objects/undo all the changes she made i.e.,
clear the things up, just before you emerge from nowhere.

Going all the guns blazing with a key-logger has its pitfalls, as John
rightly points out. You can prevent these wars by simply blocking the
offensive user (prevent mode) and keep everybody happy. Your company will
love you for not only being an efficient programmer, but also for not letting
such situations arise altogether.
 
E

Ed Adamthwaite

Hi Scott,
another way is to use VNC Viewer (you'll need to install the client on her
machine) and do screen captures of what she is doing. Show these to the
boss. Privacy and legality issues are a problem though. At least you have
proof of who the culprit is.

Send a note around to all users saying that fiddling with database queries
and design is forbidden by management. Disable the shift key and hide the
database window as previously suggested.
This should be enough of a deterrent to most users.
Cheers,
Ed.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top