Gustav Brock
Gustav at cactus.dk
Fri Sep 9 12:01:39 CDT 2011
Hi John You could have the EatBloat code from Max (where did he go?) to read out some or all objects to text files in your repository. Should you need an old version of your app, read back the set of files of that version. I do it simpler. At a given state - usually after some major batch of changes or just before deploying the app - I zip the app appending manually the next version number to the file name, like MyApp_027.zip. /gustav >>> jwcolby at colbyconsulting.com 09-09-2011 18:37 >>> Charlotte, I do version control in my C# code, at least I check stuff in etc. I really just use it for the code repository, not really for versioning. One problem I have is that I am solo. I do not the training to actually use a VCS to create and release versions, mark changes as verson XYZ etc. I use SVN and we check in changes, all that stuff. But how is that used to roll back a specific change? I dunno. If I understood that I might have the impetus to get Access working with that but if all I am going to do is check it in it seems less than useful. In the case of my C# stuff it is still useful because we can be working on things locally and only check in when it is tested etc. I.e. I can use an older version until the latest changes seem to be working. Even so it would be nice to say I want to roll back just change xyz. John W. Colby www.ColbyConsulting.com On 9/9/2011 10:59 AM, Charlotte Foust wrote: > John, > > The way to do this is with version control software, i.e., SourceSafe, > SourceGear Vault, etc. There are Access add-ins that allow you to use the > version control software in a comparable manner to other languages, that is, > at the granularity of inidividual containers within the project. You would > need to look at what's out there, and the software isn't cheap, but there's > a good reason for that. Of the two I've worked with (those above), Vault > gives far greater control, but I admit I never worked with it in Access, > only VB.Net. > > Charlotte Foust > > On Fri, Sep 9, 2011 at 4:52 AM, jwcolby<jwcolby at colbyconsulting.com> 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? >> >> -- >> John W. Colby >> www.ColbyConsulting.com