Securing a Database

[Steven]

I have an access database on a network. What is to
prevent an upset user from one day copying the database to
their C:\ Drive ; waiting a few days and then copying
that old database back over the current day.

Here is a current plan I have:

If you cannot prevent them from copying and deleteing is
there a good way to test the database to validate that it
is the current database. I was thinking of creating a
Tester database in a directory that nobody knows about and
everytime a trasaction is processed in the main database,
(ie MainDB), it would take an incremental transaction
number and log it to the Tester database. For example,
MainDB TransLog# is 1000. This means the TestDB TransLog#
must be 1000. When a user tries to append or update in
the MainDB it will test these numbers. If they are not
equal then the MainDB will stop everyone by a value in a
special table. If the numbers agree then the
append/update will proceed in the MainDB and the TransLog#
in both Dbs will increment to 1001. This way if someone
tries something sneaky, and there has been a new
transaction, then the TransLogs will not agree. That is
unless that person understands my system and knew how to
keep the Tester DB with the MainDB, which I doubt they
would know. Is this a good idea or is there an easier way.

Thank you for your help.

Steven

 

[TC]

Rather than using a hidden Tester database, I would write the transaction #
to the windows registry. (Check out the SaveSetting & GetSetting functions.)
Or, you could even save it as a front-end database property (check out
CreateProperty). Both of those would be much cleaner than having to worry
about an extra database, & what happens if that database goes missing etc.

Remember to allow for the case where the database becomes corrupted, & is
restored from backup by an authorized person! If the transaction # was in
the registry, the authorized person could run a simple .REG file to reset
the # to zero. The code that checked the # could say: "Oh, it's zero, that
means that I should start again".

HTH,
TC

 

[Steven]

Thanks for the response. I will have to look into these
things. They are new to me.