Best practice for deploying Database

[saudkazia]

Ok. Suppose I now have a database which is the final version. I have compiled it to an ACCDE and its to my requirement. Oh no. I just realized that something has changed that I need to edit this Database. I can't because it's compiled executable. Before I get into such a situation can someone explain what is the best method to ensure the following.



Database deployed locked down with no changes to design and code as ACCDE
Database front end and back end can be easily changed and redeployed from the master saved ACCDB

I think splitting the database is the common practice but how can we do this ensuring the above

[ranman256]

yes, splitting is the way.
Every change to the FE, deploy to 'site' for users to download, then send email to get the new copy. (or just email the new copy)

[jan.simpson]

Saudkazia

This is how I distribute databases to end-users...

1. Split db into Front End (FE) and Backend and use 'linked' tables
2. Save your FE .ACCDB as .ACCDE
3. Copy your .ACCDE to .ACCDR (using Windows Explorer or CMD/PowerShell)

The .ACCDR is a 'runtime' version of the .ACCDE and provides all the benefits of the /runtime switch
One thing to watch out for is that you cannot open a .ACCDR from the ACCESS console, your users just double-click on it or create a shortcut for the desktop.

When you need to improve or bug-fix, open your ACCDB and perform steps 2 and 3 again.

If you don't want users to be able access the Backend (if it's an .ACCDB backend), create an AutoExec macro that will display a message "Not ALLOWED!" and Quit Access.

If you have SQLServer or other ODBC connected backends, it's even easier

I keep my FE code in a secure folder location, compile and create the .ACCDR for distribution.


The .ACCDR is a RunTime version of the ACCDE which means that users cannot access any of the database development objects.
The can use all objects, just not get to them in development mode.

If you set your ACCDB/ACCDE options for "current database" to <Display Navigation Pane> to FALSE (No) (not ticked) and same for <Use Special Keys>, users cannot 'break in' or access any part of the development, plus you don't need to use a password to access the database. The "current dadtabase" settings 'stick' to the .ACCDE/.ACCDR

Good luck!

[NTC]

actually before jumping thru too many hoops - - the appropriate deployment really depends on the user base; for trusted employees all on the same LAN - it can be quite simple; just link 1 front end, copy it, and put on each user's PC (this presumes uniform drive naming).... compile, runtime, etc may or may not be needed - its not that they are bad ideas but just may be unnecessary - again - depending on your user base...they are a little bit of more work to manage going forward.....

[ItsMe]

Yeah, I don't think the answer to your question is any more complicated than keeping you master copy of the front end in a secure area where you manage development. When you create a new version, distribute a copy of your Master to the Users and destroy all previous versions.

Also, there is not any need to change an accde to accdr. Just distribute the accde. When I am creating accde's and locking down an app, I use a special, separate, folder. When I start, this special folder is empty. Then, after the accde is created, I move it to the 'Distribution' folder.