Many thanks all for your fantastic replies.
I am just going to finish off the database (with some assistance) and then i'll have a go at "securing" it.
Kind regards
Neil,
Here's some quick ideas:
1. Make sure all your back-end tables are hidden (open the properties for each table and enable the 'hidden' option).
2. Minimize the database window to the very lower left corner of the screen--try to drag the minimized window beyond the bottom of the screen.
3. Disable special keys in the front-end by selecting Startup options, advance settings--this will prevent users from using the 'F11' key to display the database window.
Some other ideas--a bit more lengthy:
1. Placing the back-end in a network share (folder) on the server with NTFS permissions for only those users you would like authorized for access--good idea. Another option is to code a form on the client applications that validates application users based on their network domain names (great for Active Directory networks)--this would be an environmental variable (I have done this on a project I am currently working on myself). To view a username system variable, open MS-DOS:
1. START>Run>Type 'cmd' and press {Enter} key--this will open a command-line window.
2. At the prompt, type 'set' and press {Enter} key--this will list your system's environmental variables.
3. Look for 'USERNAME' at the bottom of the list--you can use this variable in Microsoft Access with a little VBA code in an event procedure.
2. I would create a self updating front-end. This can be accomplished by creating a couple tables, one in the back-end for the current application version:
Back-End Table (Linked Table)
Name: tblCurrentAppVersion
Field: CurrentAppVersion
Type: Double
Front-End Table (Local Table)
Name: tblAppVersion
Field: CurrentAppVersion
Type: Double
Basically, you create the two tables--one in the back-end, the other on the front-end. Then 'link' the back-end table into the front-end application. Afterwards, create a splashscreen that displays when the application launches. Then create an 'event procedure' for the 'OnTimer' event--code the subroutine to validate the application versions are equal. If they are not, then call a batch file (from the subroutine) to uninstall the old application and re-install the new. The batch file should be coded to delete the old front-end on the network client (the user's computer) and install the newest version from a network folder onto the user's computer. Meanwhile, have the splashscreen validate permitted users using an event that takes place 'after' the timer event.
This method ensures that only those user names coded would be permitted to use the application--you could code a messagebox that would display for unauthorized users and quit the application if a user wasn't listed.
Finally, the batch file could not only be coded to uninstall and re-install the new application; however, the batch file could also open the new application for users; thus, a user would not have to do anything in order to update--it would be 'transparent' to the user. In a batch file, you could use this command-line code (your batch file) to open an Access application:
Start "C:\Program Files\Office\msaccess.exe" "C:\Program Files\%Application Folder%\ApplicationName.mdb"
The line of code above would start the application after updating, the uninstall/re-install routine. In effect, the user just clicks the icon to start their application, then the splashscreen would check for the correct version, if not, the batch file would uninstall and re-install, then launch the new application for the user. When the new application launches, the splashscreen would appear again, check for current version (which it would be), then...(important point here) the program would validate users. If the user was authorized, the application would continue to the main menu (switchboard).
Another nice thing about using a batch file for installing/uninstalling, etc. You can create a log file of users updating and installing the application completely hidden from the users--I do this as well. Would look like this:
X = Mapped Drive to Network Share (You Could Use UNC Mapping As Well)
Note: The '>>' symbols in a batch file appends the output to a text file, not to the screen--this avoids confusing your standard computer user. A single '>' will overwrite the file (don't use this symbol).
echo. >> "X:\ApplicationFolder\Install.txt" (Creates a blank line in log file)
date /t >> "X:\ApplicationFolder\Install.txt (Records date in log file)
echo %USERNAME% >> "X:\ApplicationFolder\Install.txt" (Records user name in log file)
echo %COMPUTERNAME% >> "X:\ApplicationFolder\Install.txt" (Records computer name in log file)
xcopy "X:\Application Folder\ApplicationName.mdb" "C:\Program Files\ApplicationFolder\ApplicationName.mdb" >> "X:\ApplicationFolder\Install.txt"
In short, every time a user's application is updated via the batch script, your log appends the details of the installation in the Install.txt file. However, why not take it a step further to make sure only certain people install the application with your awareness. Use MS-DOS 'net send' to send yourself a system message--I do this as well. Looks like this:
net send MyUserName "%username% - Successfully installed applicationame versionnumber" > nul
Note: The '> nul' tags are used to disabled output on the screen--the user won't see this on their screen, nor is it output to a text file.
If you have questions, feel free to send me an e-mail anytime.
--
Best regards,
Todd Shillam
Information Technology Consultant
Shillam Technology
http://shillamtechnology.point2this.com
I will be splitting up a database and will be putting the backend on a
server drive and the front end on certain individual's desktops. Now, I
would like to password the whole backend of the database just in case
somebody manages to find it and play about with it. Nonetheless, I don't
want to put a password on the frontends, nor do I want the users to be
prompted for the backend password when they open the frontend.
Is this possible? If so, how?
