Packaging Software - Avoiding Overwriting User Data With New Software

[mas5]

I am working with a user testing new releases and am new to packaging Access applications.

My application is split into a back-end database where the table definitions and the data reside and the Access application where all of the forms, reports, etc. reside.

When I package the application if I were give the user a new set of table definitions and the user loads then up using the setup package that the Packaging Wizard creates then all the data created will be deleted and replaced with the new empty tables that I provide.

I would like to confirm that my strategy for avoiding this loss of data is correct. I'm hoping that there is an easier way to do this so if anyone has any advice I would greatly appreciate it.

After the first release of the software to the user I would never include the Back-End tables with the software release. Any new tables or altered tables would be delivered with the Access Application.

The first time the user runs the application after the new software is installed there would have to be a small application that would check which release the user used the last time the application was run. (I do have two small version control tables in the application that store the version number of the software. One table is in the backend, one table is in the application. I compare the two version control tables and if they don't match I know that the new tables haven't been release to the user back end).

Once I determine that I have to release new tables I will use macros to export the new table definitions to the back end. Then I'll drop those new table definitions from the front end. I'll make alterations to existing tables via SQL. Then I update the version control table in the back end to the new version.

Does this strategy sound like the way to go or is there some easier way to do this within the Packaging Wizard?

Thanks much for your time and advice.

 

[MichaelRed]

I would probably try yo use the datemodified properties of th tables to determie / define the release. To do so, I would maintain a template version of each table in the FE. These tables would be empty, and have a distinct name relation to the corresponding BE table (e.g. BE table = "tblCust"; FE (template table) = "tblCustPattern". Each release / installation would compare the datemodified properties of the FE and Corresponding BE tables, and check that a corresponding BE table actually existed. For those which do not exist in hte BE, you can (of course) just copy / export it to the BE, with the correct name. Fo those where the datemodified property of hte FE is greater than the corresponding BE, you would need to (programmatically) review the fields and their porperties and make the changes as necessary.

You will have a few twists along this path. You cannot change hte properties of a linked table, so you need to 'open' the tables as a second database. Next, to modify a table, you must have exclusive access to it, so the entire process needs to include the mechanisim to boot users from the BE. Depending on the details of how the FE is distribuited, this may also be necessary for the FE.

Additionally, there are a number of issues which need to be considered in the distribution of a multiuser db (assuming all split dbs are split because they ARE multiuser). First, all individual system clocks need to be synchronized with the server, otherwise time-stamps are not particularly useful, and thus cannot be used to 'order' activity. Next, you need a transaction log. The premise (in this) is that whatever CAN go awry will go badly awry, usually with the aid amd consent of a human being. A useful recovery scheme is to have the transaction log. Additionally, since the BE (at least) resides on the net / server, the 'official' responsability for back up lies in the net admin (police?). They ARE faliable, so YOU need to check their activities. Ask them -in writting:

What is the backup frequency? (ONLY acceptable answer is "daily)

Is the backup log reviewed for EVERY backup, to identify each 'failure' to backup EACH file and to notify the 'owner' of EVERY failure? (only acceptable answer ...)
Does the backup process automaticall disconnect all users from files before doing the backup? (Only acceptable ...)

Can you occassionally review the back-up log for the files YOU are responsible for (e.g. the Owner of)? (Only ... )

Does the net itself enforce the synchronization of the individual workstation clocks? (Only ... )

If there are ANY unacceptable answers, foreward the entire dialog to your superior along with the rationale for why these steps are NECESASARY. If there is not an 'immediate' response, start the painful process of working your way through the organization to get this all resolved. Even if (I do not understand how such could happen) soem items are not corrected, you will at least know what is happening.

MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[mas5]

MichaelRed -

Thank you so much for your detailed reply. You save me a lot of trouble by noting that I would have to open the linked database. I hadn't thought of that. I know I have to link the tables once I export them.

I was hoping there was so magical way that the packaging wizard and corresponding setup program would just take care of things by comparing version numbers but that was a lot of wishful thinking.

Fortunately, my application will have very few users in small environments so we won't have some of the problems you note above. Unfortunately, many of the installs will be done long distance so that creates a host of other problems.

Thanks again.

MAS