Cloning method (keep your source mdb safe) (1 Viewer)

Not open for further replies.


Registered User.
Local time
Today, 09:50
Feb 11, 2008
Here's the link to the actual cloning script:

Here's the benefits of having your users get into your mdb via vb script (text below copied from my post on code bank):

Try this method out! Are you tired of having to get each user out of the front-end so you can copy new code? Do you want to see who's currently in the front-end? Would you also like to see when the user last got into the front-end? Do you want to avoid having code to "auto-logoff/auto-logout" a user and NEVER worry about a corrupt mde/mdb file because a user locked it? Don't let user's get into the same front-end mdb/mde (if it's corrupt because a user left it open, you have to track down who's in it.)

The attached script will take the front-end, clone it with the user's login name, and launch the cloned file. All done automatically by the user just clicking on 1 small vb script (less than a dozen lines of simple code where you only need to change 1 line). Then, you can simply look in the folder for a MyAppName<USERNAME>.ldb file (where MyAppName is the MSAccess file name) and you'll know that user is using the application. You'll also see when the user last opened the application by simply looking at the date created on the MyAppName<USERNAME>.mdb file.

Do not use this script on an mdb which has the MSAccess Data tables (i.e you don't have linked MSAccess data tables or SQL Server tables - it's for front-ends only.) Otherwise it will clone the MSAccess data tables as well and you'll end up with separate data tables. It's designed for frontend MSAccess mde/mdb files which have linked tables in them.

INSTRUCTIONS: You edit the vbs script (in NOTEPAD) and simply change the 1 line for LUName = which is the location of your mde/mdb file (keep the location name in " as the example illustrates.). It's recommended to use the UNC name for the location but this is not a neccessity. If you have foldernames with spaces, use the ~1 for the 8 character foldername (just like you would do for a shortcut). Save the script in the same folder as your front-end mde/mdb file (although this isn't necessary.)

NOTE: If you are using an mdB file instead of an mdE you'll also need to change the line:
newName = Replace(LUName, ".mdE", "") & GetUser & ".mdE"
newName = Replace(LUName, ".mdB", "") & GetUser & ".mdB".

'Read the comments in the script for details.

**** Edit the vb script with NOTEPAD to make changes - save it as a *.vbs file. ****

It takes seconds to modify the script. That's it! Then just simply double-click on the vb script to see it do it's thing. Have each user simply click on the vb script whenever they need to get into your application instead of another shortcut to the mde/mdb front-end. 1 vb script which all of the user's can run. Running the vb script also takes less than a second for it to clone and launch the new mde/mdb front-end.

Dan Wang and myself created this script and I have never had any problems with it. I can only possibly see problems if perhaps your system administrator has locked a computer from running vb scripts or the wscript.exe file has not been installed (or deleted) from the Windows\System folder (which is not common).

This script has many, many advantages:

1. You'll NEVER have to worry about users not being able to get into the front-end mde file because a user locked or corrupted the *.ldb file. No need to ever use any "auto logoff or auto logout" code as it DOESN'T MATTER if the user corrupts the cloned mde/mdb file they are in. Just have them get back in via the vb script again. Your source front-end mde/mdb file will stay SAFE and READY for backup at any time! It's never used! (except to clone off of.)

2. You can copy new source mde/mdb code to the working/deployment folder without having to have all the users close out of the mdb/mde file! Then just simply send an email to the user to close out and get back in (via the vb script again) at their convenience to see the new code.

3. You can see who is currently in the mde/mdb (i.e. you'll see a file such as MyMDEApplicationPaulK.ldb in that folder). No need to get a 3rd party application to read *.ldb files to see who's using the application!! Just look in the folder for *.ldb files with the user's login name to see who's in it.

4. You can also tell when that user LAST got into the mde/mdb file by looking at the creation date of the mde/mdb file with the users loginID!

5. If you have a lot of make-table queries, this is perfect as each user is in their own front-end so there's no issues with tables being locked. The next time the user get's into the mde/mdb via the script again, they will have a lean, non-bloated application which doesn't need to be compacted and repaired.

6. Users can create a shortcut to the vb script on their desktop and just click on the short-cut (when executed, it will clone the mde/mdb file, add the users windows loginID, and automatically launch the cloned mde/mdb file with the users loginID.) Just send it's location\name.vbs in an email (like you would for a shortcut). It's great for multiple users getting into the same frontend mde/mdb file (with linked tables). Each user is then working off of their own MSAccess file verses multiple users in the same MSAccess file.

7. You can tell if the user is working with the latest code changes! If MyAppName.mde is 6500 KB and MyAppName<USERNAME>.mde is 6300 KB, you know they are not working with the latest code changes. Just have them close out and click on the vb script again.

8. And you'll find less code problems with each user in their own mde/mdb front-end file.

9. The script doesn't necessarily need to be used for just MSAccess files. You can make a few modifications to it and utilize this script to clone ANY other file and run them!

Special thanks goes to Dan Wang for coming up with the initial code.

Follow the link and download the zip file. I use this method ALL the time and it has been a godsend for me. Let me know how it works for you.

I'll also post more links to some of the snippets I've already uploaded on or just search through the MSAccess code bank to see more examples by pkstormy.

Feedback is highly encouraged and welcomed (whether good or bad!)

Not open for further replies.

Users who are viewing this thread

Top Bottom