Maintain the Integrity of the Database (1 Viewer)

Hi

A bit concerned that you are saying the Db is located on the C: Drive??

Is the database Split into FE / BE ??

Yes, it is FE and BE. the BE is on a shared drive.

Try something like this:

CurrentProject.Path

will identify what location the db is in

eg

MsgBox "the Current location of the database is " & CurrentProject.Path

Have some kind of IF switch on database open that tests whether CurrentProject.Path is what you wish it to be including its name. If it is not what you expect create a Form that is opened with a big warning message and disable all the close buttons make it modal and pop up. Or get it to insist that the application is closed.

I would say use a message box but I suspect they will just close it down and carry on. Not sure that you can disable the small close in the top right of a message box.


I think that would be sufficiently obstructive and annoying.

Personally I would go to the next level above the Management Group and ask for disciplinary action to be instigated.

If someone got sacked it would sort the matter quite quickly.

For me, step one would be adding a configuration table to your back end. Table would hold "Current version" and other items.

On start up, you use a hard coded value that checks against the "Current Version". If they don't match, put up big warning box and don't let them progress. That should cut down on SOME issues.

CurrentDB.Name is the name of the front-end file that you opened. If you look into the File System Object (suggested reading topic if you don't already know about it), you can pass in that name to various functions and extract the parts as separate strings. So it would be easy to get the drive letter and path for string comparison. And the name, if it really bothers you that they rename the file.

I had an "opening form" set up and had disabled most of the common ways (and a few uncommon ones) to bypass the controlled startup. That was important because the opening form was my "junkyard dog." If the JYD didn't let you in, you would get bit by it. The form performed version, username, role, permissions, and environment tests before it allowed anyone to get into the DB.

In particular, if you have an opening form and have disabled most of the bypass methods, then in the opening form's .OnOpen event routine, you can check CurrentDB.Name to see from which file you are running and you can do quality control on that file name. It is important to do it in the .OnOpen event because ... you can issue a CANCEL to an .OnOpen event, which prevents the form from opening. If you wait for a later event, you passed up the opportunity to kick the user out so easily.

My JYD routine would check for name and location and if something was wrong, it would issue an OKOnly type of message box that said "you are going away." It didn't matter whether they tried to close that box or not. If you got into that position, the next thing that happened was my code set the CANCEL parameter to TRUE and then issued an Application.Quit (still inside the .OnOpen routine). That made it damned near impossible for anyone to get out of there and do something with it.

However, to keep it pure, you would have to create a .MDE or .ACCDE file (i.e. compiled and the source code removed) to limit the users from diddling with it. If they can copy the raw FE file, they could find and disable the opening form's code that protected everything.

I also noted something suspicious in your original description. Are your uses actually SHARING the FE file? Or do they make copies of it and run it locally?

The users will copy the front-end and place it somewhere else, create a shortcut to that one and use it.

Click to expand...

This is actually the preferred solution for a shared BE split DB. Each user SHOULD have a local copy of the FE DB file. (They should not modify it, of course.) The reason has to do with file locking. Before we go down this garden path, I think we need to verify what is actually going on with your sharing setup.

I don't know what prompts them to copy and rename the FE. Several people have given you suggestions on checking the name. What I worry about when they do this is that they could end up using the wrong version. That could do damage to the application and the company itself. You can start with version checking. Update the BE version number when you release a new FE and when the FE opens, in addition to checking the name and path, check the version. display a message, send the admin an email, and shut down the app.

Don't forget to take the advice to deliver as an .accde. I would also rename the FE to have an .accdr extension. That will tell Access to pretend to be the runtime edition and prevent access to any design objects.
And finally, when you have to clean up, make sure the time spent on doing it is itemized and attributed to the person causing the work.

Pat, I learn something new every so often in the forum, and I just learned a new trick. (Maybe I'm not such an old dog after all...) I didn't realize that if you named the file as an .ACCDR that regular Access would treat it like an Access Runtime environment.

Unfortunately, the user who actually knew anything would just rename that puppy back to at least an .ACCDE - though if the VBA source code isn't included, it is harder for the user to back it out all the way to an .ACCDB to make changes. Then again, that is really all that most security systems CAN do... make it harder to muck about in the playpen.

Hi Doc, It is a trick but a useful one. And thanks to you too. I can't even tell you the stuff I learn from your posts.

what is stopping you to only install access runtime on all their machines ?

mo9204, good question, but for this thread, only Learn2010 can answer that.

In my Dept. of Defense environment, the government bought a package deal from whoever got the "desktop upgrade" contract, usually repeated about every three years. They would provide workstations or laptops for some department that USUALLY meant 50,000-lot quantities preconfigured with a properly licensed copy of Windows, Office, some other selected utilities of interest to the security wonks, and a domain-based setup that essentially locked down the system. We didn't get a choice and it took maybe a couple of thousand people to complain about something before they would change the group policy downloads.

When you are dealing in quantity purchases, whether Dept. of Defense or a shop with a half-a-dozen employees, the power of the bulk purchase overrides such questions such as actually making an intelligent decision about the intended software environment.