Clever Geek Handbook

How to continually develop and deploy an Access 2010 database application

I am developing an Access 2010 Database Application, I will call it Skill.accdb

. I'm at the point where I want to start deploying it so users can start using it and continue developing at the same time. I read

which talk about splitting, compiling, installing, etc., but they are very short on valid procedural steps to follow.

I have split the database application into internal and external interfaces: Skill_Back.accdb

and Skill_Front.accdb

. The back-end server is on a shared network drive, and some users have copies of the front-end. So far so good, especially if I no longer need to do development. But I can't figure out how to continue development on the front-end now without breaking the live back-end.

How do I have a front-end development version pointing to a dummy back-end version so that I don't mess up the live version? And then when I want to release a new version of the front-end, how do I get it to point to the live version of the back-end again?

If I re-split (i.e. use the Move Data | Access Database tool again) to point to the dummy source code that doesn't exist yet, I was told that all the tables are now empty - not what I want. If I redo to point to a copy of the live-back-end, I am asked if I want to replace it - also not what I want. If I do this, I will be told again, "There are no tables in this database. The underlying database will be empty." and yet I can see that it (front-end) is still pointing to a live start!

What critical concept / tool / procedure am I missing? (I am not asking about compilation or runtime or installer creation - these are issues later).

addition

Further, following the advice in the subtle answer below, I found a couple more articles describing the procedures:

+3


source to share


2 answers


It is not a website or file; it's a database. You cannot update every copy of your frontend on every user machine, it just doesn't work.

The strategy I use is a "version" of my front-end boards, and when I work with databases, I don't use the built-in Move Data

Access tool .

How do I create a version of the interface that points to a dummy back-end version so that I don't ruin the life of the version?

You need (at least) two different environments

  • Manufacturing (what your users are using)
  • Testing (where you make your changes and test them)

For testing, you will need your own interfaces and interfaces. This is where you will make your continuous development. You never want to be bothered by what your users are working with, especially data.

For production, you can make your changes and deploy the new version via a shared network drive where users can download a copy just like the first one. This is where you can use Linked Table Manager

to reconnect tables to your production server and to your new interface.

So the worker thread would be:

  • You have a production back end and a front end user interface.
  • You have a copy of both of these databases to work with, and it is unrelated to what they are using.
  • You link your Front End tables to your copied front end development version via Linked Table Manager

    .
  • You change / make updates / keep evolving at your face end.
  • You test them / ensure that everything works.
  • You host your new version of the front end of the product (v2) on a shared network drive and plug it into the back end of the product.
  • Your users download (copy) the new version and use it.
  • They see your changes and wonder what you did, and you get a raise of $ 5,000.00 to know what to do and be a great developer.


Linked table manager

In the Navigation Pane, right-click one of the related tables to open the context menu. From there select "Associated Table Manager".

enter image description here

This makes it easier to manage links. Place a check mark in the box next to each linked table you want to change. Or, changing them all, click Select ALL. Also check the box next to Always ask for a new location (in the lower left corner of this dialog box). Access will then ask you to find the database source for the links.

If you need more information, just say something.

Linking new tables from back to front

If I have a database with tables and I wanted to link those tables to an interface on my desktop, I would follow this process:

  • Click the External Data tab at the top of the Access Ribbon
  • Click "Access"
  • Choose the correct file / directory name for your internal
  • Please select Link to the data source by creating a linked table.

  • Select the tables you want to import (maybe click "Select All")
  • Click OK.

You will now see the tables in your interface. You can then use the Linked Table Manager to manage these links so that, for example, your back end database is moved to a different location.

+5


source


I would suggest the following:

http://www.databasejournal.com/features/msaccess/article.php/3286111/Automatically-Deploy-a-New-Access-Client.htm



The article mentions Access 2003, but I've used it for Access 2010 databases. Basically, create a compiled front-end 2010 and when it starts up, it checks to see if the client version matches the server version. If they are different, the new version of the server is copied to the client machine. It's pretty sleek.

+2


source






More articles:


All Articles