Track form and module changes (1 Viewer)

[c_smithwick]

I have a development copy of a database that I use to push changes out to a network copy when I need to make design changes (to forms, modules and other objects). Currently I have a function that I run that calls up a list of all the objects in Access from which I choose the items to push out. I would like to limit this list to only the items I have recently changed. I tried querying the MSysObjects sytem table, but the LastUpdated field doesn't seem to change whenever I make a design change and then save. Is there a method to track design changes to forms, queries and modules, at least to the point of knowing the date/time of last change and save?

 

[Banana]

AFAiK, this has been a long standing bug. It stopped working after 2000 because of changes in how objects were stored. It used to be that objects would be stored in separate records but now all objects are contained as one huge BLOB field.

For this reason, it's usually easier to just maintain the file at file level or manually record which objects was changed (which is no fun, to be sure).

A thought, though, if we are willing to put in extra effort. I know that we can replace a default button with a custom button as well overriding the shortcut keys to the same button. I've had overriden the default copy'n'paste functionality to do something special for one form and falling through to the default functionality. Therefore, we can do the same with Save, and have it go through a custom routine that then update the timestamp of a custom properties for every open objects.

 

[DCrake]

One other solution would be to use the database documenter that I provided on the samples forum. this documents all object in the database to text files. If you copy the latest version you are working on to a know location to start with. Then make changes to a form/report/etc and repeat the exercise but save the results to a different folder. Then use the getfileinfo() command to compare the file sizes of matching filenames in each location. Then if one is larger or smaller than the other then you know it must have changed.

A bit crude but in theory it should work. I suspect though small cosmetic changes may not result in changes in file size.

 

[Banana]

Actually, I wonder if DCrake's solution is better. Instead of comparing file size, though, one would use a diff program to compare and thus highlight which objects has been changed even for tiny one letter.

 

[DCrake]

I was contemplating offering the line input method to compare line for line but I thought that this would be a bit of an overkill. It depends how critical the changes are.

A good programmer always keeps a log of changes made to a app for reference purposes anyway.

 

[Banana]

I agree that a log should be kept, but you have to grant that when this is automated, this means more time programming and less time logging and thus more productive.

Besides, I don't think it should be necessary to do a line for line input but rather say, checksum of the whole file which should be good enough to signal that the file has changed since last time it was saved.

 

[DCrake]

Re reading the intial post is seems that the user only wants to distribute the changed objects. If he is pushing them out to a central copy on a server, I hope that this copy is not being used as a multi user entry point. In theory these changes need to pushed out to each user. The only way this could be achieved is if the developer has the ability to take control of each machine.

This also means that each user must be logged out of the front end in order for Access to allow the acceptance or the objects, and if the front end has password protection on the vba it will be denied anyway, as you have to have access to the vba via protection to copy any objects to and from other databases.

I have also found in the past that exporting objects to other mdb's can cause the source mdb to freeze or crash if cycling through a series of objects. It was the case in earlier versions of Access.

 

[The_Doc_Man]

I am reminded of the old programmer's rules; specifically, the one that says Access can't tell you anything you didn't tell it first. The best way to maintain a revision history is to design one as part of the DB, perhaps in a hidden table or a role-sensitive table that only shows up for folks authorized to change it. There is no substitute for a disciplined approach to project tracking, based on the simple idea that a thing worth doing is worth doing thoroughly and well.

 

[c_smithwick]

Thanks for all the help and suggestions guys.