jwcolby
jwcolby at colbyconsulting.com
Fri Sep 9 06:52:56 CDT 2011
I use a somewhat simple two table change request database for tracking changes to my Access projects. I have to admit I find it problematic to track changes to a level that allows backing out any specific change while leaving the rest. This has resulted in "rolling back" to a specific level when a problem comes up. And yes they do test but things do happen. I have a CR table where the client places their change requests with explanatory text. It has the typical requested date / requesting person / date to test / date tested etc. A child table holds what I do with explanatory text and a test regimen to test that it work, a text for what they found in test (if problems). I can add another record as a response to that testing problem etc. The problem I run into is that any significant change may involve a change to N queries, additional fields or entire tables, code modules and so forth. A change may be trivial or it may be an entire subsystem. I have never found a way to really document in sufficient detail what I did to implement the change that would allow me to back out just that change, at least of the change is very complex. If I get two or three changes in and then one four changes back is found to be a problem such that they want to roll it back, I often times cant. If we roll back all the changes since (go back to a previous version) then we lose all of the actual work done since. I have never worked in a large design team and witnessed how this is generally done. I am wondering how you guys handle this stuff. Any words of wisdom? Tools? tips? Can we have a discussion on this? -- John W. Colby www.ColbyConsulting.com