Access (97)

Topic

New Reply

I have a replicated database which contains confidential information. This has to be tranported between sites on a CD. How can I make it so unauthorised people can’t gain assess to it. It is used by non-technical personnel!

Reply | Quote

Replies

You could use a simple login screen that runs at startup and must have the correct code in the textbox before anything else opens.
Is this what you need or am I up the wrong tree?

Reply | Quote

Thanks, yes, that could be just what I need – but how do I do it?!

Reply | Quote

The suggestion by Jonathan is to create a simple form where you have to type a password and then code on the form checks to see if it is the same as the predefined password. You then use the Tools/Startup menu to tell the database to open that form any time it is opened. The downside to this is that a knowledgeable user can bypass the startup process by holding down the shift key.

A more secure approach is to apply a password to the database by using the Tools/Security/Set Database Password menu. Of course if you forget the password, you may have to invest in a password cracking tool. In that same menu you can also encrypt a database.

The ultimate in security is to do all of the above and then active the Access security system by giving the Admin user a password, and then use the Security Wizard to nail everything down. Hope this helps.

Reply | Quote

Thanks
The main problem is that you can’t have a password on a replicable database, so unless there is any more secure method, I think I’ll have to go with Jonathan’s method, full blown security won’t actually stop the viewing of the database – will it? – is there not a way of ensuring that pressing shift doesn’t work? – I’ve got a feeling there is???

Reply | Quote

Yes, you can prevent the use of the shift key, and keep people from seeing the database container window. Of course that also affects you. The trick most people use to get around that is to put a hidden button on the splash form that you open when the database is started. There have been recent threads about that – search for hidden button. If you want to get fancy, you can even put a password in the code the unlocks the database.

You are correct that you cannot put a password on a replicated database, but I believe that it is possible for a replicated database to be encrypted, though I haven’t tried it. That’s the only protection native to Access that will prevent someone with a file editor from browsing through an mdb file – they would need to know alot about the file structure to find anything useful however. Full security done with the wizard gives you the added protection of a userid and also lets you set permissions on specific objects and capabilities, but the admin cost must be considered.

I’m curious about a couple of things. Is you database split into a front-end and a back-end? Also, why did you choose replication and a CD transfer process – that seems slow from a synchronization point of view, and likely to lead to lots of conflicts? Anyhow, I hope this helps you.

Reply | Quote

Thanks for your reply, but how precisely do I prevent the use of the shift key!?
Creating a replicable database, and then using the database on a CD as the transfer mechanism is the only way I can think of. The database is at site A, site B, 3 miles down the road, also needs a copy with and uptodate(ish) client list. There is no network connection between sites neither is the company prepared to fund a modem connection and also because Site A has a seperate budget to Site B there is also the rather petty issue of the phone bill! – Have you got any better ideas?
In effect the 3 databases are more or less the same – there will be minor differences by the time I’ve finished, but there is no ‘front end’ or ‘back end’.

Reply | Quote

To prevent the use of the shift key, use the Tools/StartUp menu option, and turn off the option that allows the use of special keys. There are some other options here too that you may want to play with, depending on what you want your users to be able to do.

As to the replication issue, we haven’t talked about how large the client list is. It might be possible to use the old floppy disk transfer routine. That may be a good reason for splitting off the data tables (back-end) from the queries, forms, reports and code (front-end). The bigger issue however, is who updates the client list. If it absolutely has to be done in both places, then you may not have a choice. If however, one segment is updated by one site, and the remainder by the other site, you could simply have two tables and use a union query to present it to the user as a single table. Replication is a useful tool in several situations, but it also introduces significant complexities, and makes you database considerably larger in most cases. You also need to have a strategy for dealing with conflict resolution (Site A updates a record at the same time Site B updates that record, so who wins?).

You also mention 3 databases, but you only have two sites. Are you referring to the copy you keep as the developer, or is another location involved here? Hope your day has gone well so far.

Reply | Quote

Turning off the Tools/Startup option that relates to special keys does NOT affect the shift key. Search for allowbypasskey – it’s been discussed several times.

Reply | Quote

You are correct – mia culpa – Allison – search online help for the property AllowBypassKey and you should find it’s description an an example of code that will create the property and set its value. You might want to search this forum for that as well – there are some issues to consider.

What I told you in the previous message will let you do the rest of the job of keeping people out of what they aren’t supposed to mess with. Another strategy is to create an MDE file for the front-end so users can’t do any undesirable changing.

Reply | Quote

Thanks – actually there is a client list and the orders placed by the clients. The orders table at the moment is about 22,000, but that is 2 years worth of data and creates a database of 36Mb. The tables, in the fullness of time can be archieved so I don’t think that size will be an issue. There are 3 databases because of the ‘transfer database’ – the one kept on CD, to be moved between sites.
There will be several people actually updating the database, which must be done at both sites – the clients are not unique to each site, however, only the secretary ( a shared post) will be doing the sychronising and she will have to take the decision about conflicts, which should be rare (hopefully).
I am very grateful for your help.

Reply | Quote

We recently work with a project somewhat similar where one copy of the database was in Denver and the other in Phoenix and we moved data to Phoenix on a CD. It sort of worked, but the conflict resolution was an ongoing problem. The fundamental issue turned out to be that they insisted on using AutoNumber fields as their primary means of looking things up. That imposes a number of limitations on replication – if you haven’t already read up on that issue you might want to.

Does all of your orders information need to be replicated, or is it just the client table. If so, you might find partial replication to be the best answer. Or if your client table only updates infrequently, you could insist that the secretary be the only person allowed to add new clients, and just copy the table back and forth, probably just on a floppy, and avoid the replication challenges.

I don’t mean to discourage you from using replication if it’s the right solution, but it does add significant overhead to both the database and to the developer’s job.

Reply | Quote

The simplest solution would be to apply a password to the database, but that doesn’t prevent people from snooping with a disk editor. To prevent that you can encrypt the database – it wouldn’t protect you from industrial strength decryption software, but it would deter the casual user. Note that if you are transferring databases on CD, they will always be marked as read-only.

Reply | Quote