Version Control Question

[LesK]

I have a production database split and running as a front and back end on our network. The front end is an .mde installed on user PCs.

I now need to make additional enhancements; i.e. new forms, new tables, queries, etc. I also want to clean up the .mde and remove test tables/links, queries, forms, etc. no longer needed.

I have the development copy from which the current .mde was made and also a version in which I am doing the new work.

Any suggestions on how to evolve into an uncluttered version of the development software for the .mde? I expect that I will have to do any number of evolutions of the production version as needs change over the next few months and want to maintain total integrity of the production system and its development copy while rolling out the changes.

TIA.

 

[scking]

We do the same thing. When we release a new version to the customer we need a nice easy way to ensure they are using the correct versions of the front end and back end. Our solution is to develop a version numbering scheme and create new database properties on the client (front end) and server (back end) which store both the version number and version date. Whenever the user opens the front end a comparison is made between the version number and date in the client with the version number and date in the server. If they are identical then the databases are in synch and the startup proceeds as if nothing had happened, but if they do not compare they are not in synch and the user receives a notice of the differences and is forced to either relink using a custom form or exit the application. This works very well and in a perfect world where no one makes configuration errors they don't even know it has been done.

Steve King Growth follows a healthy professional curiosity

 

[LesK]

Thanks Steve, a good idea.

What I also need to figure out is how do I get new tables, forms, queries, etc. into the production version from the development version and also remove the unneeded test forms and queries from the production version. I want to wind up with a clean production copy that has only the forms and queries that are actually running.

Do I just have to import new stuff? Also how do I get forms or queries that have been modified into the production version? Delete and import?

Thanks,

Les K

 

[scking]

That would be done with a release. I can't picture trying to manually update Access objects on a production version. There is just WAY to many things that can go wrong. We normally have the server on the network and email the zipped executable for the front end to the users with a default directory for the installation of the application. Whenever they click on the zipped attachment the executable will prompt for the target location but if you accept the default it will go into the default application directory which is what we want. We have evolved to this method because we have very unsophisticated users at various geographic locations. Making a zip executable prevents them from having to know anything about WinZip or any other zip programs.

Steve King Growth follows a healthy professional curiosity

 

[LesK]

Exactly.

My question is, how do I create the release? I have a test/development version for new work. Once this new set of stuff is running, how do I get it into the copy of the production release from which I will create the .mde to send to users? There may be new forms or modified forms that have to move over into production. Is there a neat way to be sure that all the changes are moved?

 

[scking]

You need to inform us what the difference is between your development copy and the production copy. Is one and .mdb and another a runtime or what? I'm confused what your problem is. Our development copy is the copy used for version release and therefore becomes what you are referring to as the production copy. We also keep it is SourceSafe for version control.

Our process:
Check all changes into SourceSafe
Get the Latest changes in SourceSafe
Compact the SourceSafe copy and remove from version control
Rebuild a SourceSafe copy
Prepare for release.
Perform unit testing.
Package it as a zipped executable.
E-Mail to operations.
Operations performs distribution.

There is no need for us to determine what the changes are prior to release.

Steve King Growth follows a healthy professional curiosity

 

[LesK]

OK, then you are using the same version for new development and production once the testing is done.

I was thinking to use a test/development version and then move the finished changes to a clean version which becomes production after checking to make sure it works OK. That's because I have some test forms and queries which I want to remove from the production version but I want to keep in the test version.