Best way to give end users access to database? (1 Viewer)

We have almost finished testing our database and will be looking to go live with it soon.

In terms of preparing the database for end user access (approx. 50 people on and off) is it best practice to leave the database in .accdb format and for users to load it via Access on their own workstation, or should the database be converted into an .exe so that it can be run independently from Access?

any help much appreciated.

Hi. Unfortunately, there is no way I am aware of to convert an ACCDB into an independent EXE file. As for best practice, it is recommended to distribute your database as a ACCDE file.

Agree with the previous comments
What you can do is distribute your database & other related files as an EXE file for installation on another PC.
However it is not possible to run the database without using a copy of Access - full or runtime

Many thanks for the replies. Makes sense that Access itself is required.

Cheers

I believe that if you have the Access Runtime file available (also called MSACCESS.EXE, unfortunately - so it can be confusing...), you can create an .ACCDE file and the run-time version is legally distributable. Only the developer needs a legal full copy of Access.

However, you need to do extra testing on the .ACCDE and Runtime combination because there are a few "gotcha" cases that sometimes crop up for that pairing that would NOT show up for the developer copy of Access and the .ACCDB version of the app.

out of interest, you can either install access runtime, or install full access and not licence it, and it will revert to runtime after a short period/number of uses.

you can simulate the runtime environment by changing the file extension to accdr, rather than accde or accdb.

gemma-the-husky said:

install full access and not licence it, and it will revert to runtime after a short period/number of uses.

Click to expand...

I didn't know that.
Thanks for the tip.

I wouldn't use that "tip". There is no advantage to it since the runtime is freely available and as with all "tips" of this type, you run the risk of MS doing something you didn't expect.

I use a batch file to distribute new copies of the FE to each user. So to add a new user, someone sends him a shortcut to place on his desktop. The shortcut runs the bat file which remains on the server. Using this method, each time the user runs the shortcut, a new copy of the FE is downloaded and replaces the old copy. This gives you a pretty flexible environment. You should avoid distributing updates during working hours whenever possible but in an emergency, you can send an email to all your users asking them to shut down and reopen the app. You can carry this further if you have a need and use tables in the BE that are checked regularly to control forcing a shut down. But first things first. Here is the .bat file I use:

md c:\DwgLog
del c:\DwgLog\DrawingLog.accdb
copy "\\BSCCTIMBERLINE1\Timberline Office\AccessApps\Data\CommonFE\DrawingLog.accdb" c:\DwgLog
c:\DwgLog\DrawingLog.accdb

Change the file and directory names to suit your app.

Here is the Citrix version of the file if you are using Citrix for any users:

md %USERPROFILE%\DwgLog
del %USERPROFILE%\DwgLog\DrawingLog.accdb
copy "\\BSCCTIMBERLINE1\Timberline Office\AccessApps\Data\CommonFE\DrawingLog.accdb" %USERPROFILE%\DwgLog
%USERPROFILE%\DwgLog\DrawingLog.accdb

As you can see, for this client I distribute the .accdb. These users are all professionals and are not inclined to break in to the app but if you prefer, you can compile the app to .accde and when I do that, I rename the app from .accde to .accdr because the .accde still allows the user to modify tables, queries, and macros if he is using a full version of Access so it doesn't provide much protection. You can also rename the .accdb to .accdr. Access doesn't really care what extension you use but the .accdr extension adds some additional protection in that it forces whatever version of Access that opens the app to operate in runtime mode. That means that you cannot put ANY object into design mode while the file is named this way. The user would have to be aware that he needs to rename from .accdr back to .accdb in order to get to design view on any object. Remember the .accdr trick is not real protection but if you dont' tell your user how to get around it, they are unlikely to work it out.

.accdr is vital to use as a developer for testing if there is any chance a user is going to be using access runtime.

To my mind the most useful feature lost in runtime is shortcut menus (right click to sort/filter etc). You can build replacements. Also lost is the spellchecker.

You also need to ensure your code has strong error management. Runtime will not generate a detailed error message, just a generic 'there is an error' message, and then close