Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

How does everyone do their database version tracking

Status
Not open for further replies.

mustangcoupe

Technical User
Joined
Feb 26, 2003
Messages
221
Location
US
I now have a month or so of developmental database versions... I was thinking I need to implement some type of database version tracking does anyone know of any premade modules to actually track my changes? or should I just make a table I can add the changes/version numbers to? What do you do? I guess I decided my current way of keeping all the old ones just wont work... (I cant remember what was the difference between 0.0.1 and 0.0.2 now that I am up to a 1.0.0 that my coworkers are now using....)

thanks for your input

--Todd


TechnicalUser pretending to be a programmer(shhh… the boss doesn’t know yet)
 
Im not looking for user changes... (I ment programing changes if I was unclear)


--Todd


TechnicalUser pretending to be a programmer(shhh… the boss doesn’t know yet)
 
pony,
Don't know if this is exactly what you need or not.
I immediately (on creating a table, query, form, report, macro or module,) rt click the item, click properties and enter a description of when i created it, what it does and list the various other tbls, querys or forms that are used or that relate. This method has been very useful on many occasions.
jim
 
pony,
One other thing. You could create a table, have a couple of fields; /autonumber,date,changes/ and use the comments as the changes field. As long as you are "religious" about entering the comments it should give you a great way to track changes.
 
I've got 2 tables. One that contains the names of each of my databases and the date/time of the last revision and the reason for the revision. After I add the reason for the revision and prior to closing, I update a Custom database property with the current system date and time (which stays with the database). Now, if I need to know if the user has the most up-to-date version, I can either check the Custom db property programmatically or via the Help menu I pop up a form that gives me information such as the date/time of the last revision, name of the computer, where the tables are linked, etc.

I have another table that contains the name of the computer, a new version flag, database name (optionally, a Broadcast message flag, a shut down flag, primary user of the computer, user's phone number and office location). At startup, the program checks to see if the computer has been "registered" (i.e. record contains name of computer). If not, then I pop up a form and have the user enter the required information. If the computer is already registered I check the newversion flag. If it's set, I launch a batch job and exit the current db. The batch job copies a new version of the database to the user's machine, and restarts the db. Also at startup I open a form (hidden) that runs on a timer. And every so many minutes it checks to see if a message is to be broadcast to the user's machine (i.e. system going down in 5 minutes). It also checks to see if the db should shut down (i.e. user didn't log out as asked so I log the user off via Application.quit). By having individual flags for each computer (i.e. newversion flag, broadcast message flag, etc), you can control who gets the new version or a broacast message. Say, for example, you have a new version that you want just a few user's to have to that they can test it. With this method you can set the flag for just the pc's you want to have the new version.

One nice thing about keeping track of the primary user and phone number, etc is if I need to know who's logged on, I can run a function that does that and also can display the phone no. etc in case I need to get in touch with the person.

I would put these functions and tables in a library database that can be used by other databases you develop. A library database is just another database that you reference with your current database. And you call the library functions just as if they existed in your current database. And you can add functions to your library database as needed.

Finally, although the method I described above would take a little time to implement, you can do just pieces of it as time permits. Once fully developed though, really comes in handy for other pieces you will eventually need to maintain multiple database with multiple users.
 
what I have for the user interface (I know from another thread, you didnt like this method because you can't tell right away all the information you have) is a table linked from my BE and a table in the FE then compaire the two fields and download the latest update if there is one.

I also have a table with a logout/shutdown app flag ( I think I will combine some of these into one table.

BUT my question was about revisions... how do you keep track of changes and which version has what changes and why... I guess it would be just a log of some sort....
xaf294 said:
One other thing. You could create a table, have a couple of fields; /autonumber,date,changes/ and use the comments as the changes field. As long as you are [red]"religious"[/red] about entering the comments it should give you a great way to track changes.

problems being remembering to be religious about this.....

--Todd


TechnicalUser pretending to be a programmer(shhh… the boss doesn’t know yet)
 
I'll tell you what my problem was historicaly: updating the be's and including new components.

Using installer2Go and an update feature I created, I pretty much solved the problem.

W/ I2G I can include new dlls' and components.

To update the datafiles I have done this:

I have an update table; it holds information on what updates to perform to data dbs, or Be's. The table also has a boolean field that says if the specific update has been performed or not. Everytime I create an update, I distribute the fe with the new update table, it contains all past updates, and all are unchecked.

When the fe starts it checks to see if there are any unperformed updates, if there are it tells the user to make sure no-one is using the system, then it runs through the updates and updates the be. The update table contains a field for custom functions, and also a upgrade type. This way I can make tables, edit fields, indexes, relationships all through the table, but i can also run code through the update table.

Mark P.
Providing Low Cost Powerful Point of Sale Solutions.
 
I use tables to store the database versions (front end and back end). When ever I upgrade the database, I upgrade the related version number.

The data is stored in my control table for the back end...
AdminVer 1.2001

A similar approach is used for the front end.

The cool thing is that the main forms can either use a small sbuform that displays the version number, or use an unbound text box to display the version number.

The subofrm or text box can be made to seamlessly blend into the main form. The end result is that the version number is displayed on the form.

I use a similar approach for displaying the site name (or company name) on the form.

This way, I can programmatically determine the version number, and the end user can see / recite the version number depicted on the form.

The administrative thing is to make sure the version number is properly updated for consistency.

Richard

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top