[AccessD] Access versioning / tracking changes

 I work along similar lines and have never found a good way to handle this
either.  I try and keep my changes small and do them one at a time, making a
copy of the DB with each change.  But trying to document everything and
anything I change just takes too long.

 And like you, if the first change in a series of four needs to be un-done,
then I can either go to a backup and loose all four or try to take out the
first one manually.

  I've never done the latter though.  Generally I want to get a client up
and running as fast as possible, so I'll either fix it quick (if I think I
can), or I simply drop back to the last known good copy and loose all four
changes. 

 I suppose I could use Total Access Detective like Dan suggests and try to
pull out the first change, but I've never tried to do a rollback like that
and it always seemed to me to be more trouble then it was possibly worth.

Jim. 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Friday, September 09, 2011 07:53 AM
To: Access Developers discussion and problem solving
Subject: [AccessD] Access versioning / tracking changes

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
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com