[AccessD] Access versioning / tracking changes

Hi John,

I'm impressed that you do track changes to this extent.  I don't - my method
is just fix as needed when needed.

One thing you might look at: FMS has a tool called Access Detective.  It's
used to tell you the differences between any two mdb files.  If you keep a
copy of each released version, you'd be able to compare, in detail, your
current system with any previous released version.  Long ago I had a copy of
Detective, but that was before I understood the process of developing!

HTH,
Dan

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Friday, September 09, 2011 6: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