How to deploy my Ms Access the right way?

[bmkol]

Hi
After I finished my project that has 2 files (splitted) .... how do I deploy it to customers with no chance to make chenges and to be able to install it in any computer (even if they don't have Access ... runtime)?

 

[CJ_London]

if they don't have a full version of access, they will need the runtime. If they are using runtime then your app needs to allow for that since runtime does not have certain functionality such as navigation window, ribbon and right click menus. And their computer needs to have windows OS

FE should be a .accde or .accdr to prevent users with a full version editing the forms/report/modules

if compiled to .accde/r you will need to know which version of access the user will be using - 32bit or 64 bit as the user might be using either. Note a user cannot have both versions on their computer.

Other issues are when the user installs, you have no control of where they install the FE and BE so you need to provide a facility for relinking. And the user may be using an earlier version of access - so ensure you provide files that do not use functionality/objects etc from later versions

I would look at using an installer which creates a .exe installation file which the user can run

look to the bottom of this thread - a number ask the same question

 

[Ranman256]

I have an access app to distribute the latest FE copies to all users.
This way their shortcut always opens the correct version.

 

[theDBguy]

Hi. To run an Access database, the user needs the Access application (full version or runtime). Without any Access application (including Runtime), then they won't be able to open the database.

 

[oleronesoftwares]

I have an access app to distribute the latest FE copies to all users.
This way their shortcut always opens the correct version

So if you have an access app(do you mean a copy of ms access that can be installed on each system)

If that is the scenerio then,your access database(front end must have a routine that checks for the location of the backend, whenever it loads, and if the location is broken, it should prompt the user to re-link it, the re-link functionality should be at the click of a button, macros can do that.

You can also have user table, user rights created that will limit access to some features ,so users at the front end can focus on just using the application.

 

[Pat Hartman]

Are these internal customers or external customers? If they are external, will they have their own BE that needs to be installed?

I have products that are sold to customers. They are not "shrink-wrapped" and come with support and upgrades. The setup for the BE is separate from the setup for the FE because the app is multi-user and all the users at each client will be sharing a BE. The client also has the choice of installing an ACE BE or a SQL Server BE. When I have updates, I send the client a separate install that replaces the old FE in the distribution folder and then as each user opens the app, he automatically gets the updated version. If I have to change the BE, I create a script that the DBA has to run if the client chose the SQL Server BE. For ACE, I create a special application that converts one specific version to another. One of my policies is to never remove columns or tables. If they are no longer used, I just leave them there because technically, the data belongs to the owner and is not mine to destroy.

You need much more security for a product you are selling but more important is a good license agreement with teeth. The app I sell isn't one that the employees would be inclined to steal and try to sell to others. The install requires a license key also.

We need a lot more information about what your target audience is.

Always keep in mind that Access FE and especially BE's are NOT secure no matter what you do. You should never store data in an Access db that has a market value since an employee can simply copy the BE, break it, and sell the data.