Tina Norris Fields
tinanfields at torchlake.com
Fri Sep 9 09:07:18 CDT 2011
John, I like your idea of using a database to track changes. I think I'll adopt it. I use a running notes document with dated entries. Each entry explains what I did and why, including things like working out the logic to do a certain new thing my client wants. At the end of every entry I have a list of the new items created and the existing items modified. The details of all those things are in the narrative of the entry. It can be tedious to go through, but it beats the heck out of having no idea how I got where I am at present. T Tina Norris Fields tinanfields at torchlake.com 231-322-2787 On 9/9/2011 7:52 AM, jwcolby wrote: > 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? >