Okay...there are two categories of people who design databases (and other programs for that matter):
1. Those who neatly keep track of changes they make between the "working" database, the one that you give to your end-user, and the "testing" database, the one that has all the extra crap that you don't need but keep just in case you do.
2. The ones who go insane trying to keep track of the changes because they don't have an orderly method/system of doing it.
I fall into #2. Does anyone have ideas on how they keep track of changes between the working database and the "prototype," or testing database? Keeping track of all the changes, especially the little ones, to forms, queries, reports, modules, etc. is very stressful...at least for me! Right now I just note the name of the object being modified in a text file while I'm modifying the prototype db. When I get everything situated, I open the working database and import all the objects listed in the text file.
This can be a bit of a nuisance if you make a change and just forget to note the name of it. Then importing is a nuisance because I either import it, delete the original and rename the new to the original name OR I delete the original and import the new, which seems to work "best."
If any of you experienced programmers have any good ideas, PLEASE impart them to me and the rest of the Access dBforum. Thanks!
I believe there are some tools to compare two databases. but as far as I know they don't compare VBA part of it, just database schema. field changes, releationships, etc.
do I use them? actually, no I have a notebook that I write the changes I made to database.
I always discourage maintaining two databases. When I go to make changes to the "live" database I first archive it then I make a copy which I use to develop. If I want to use that copy I replace the live on with it. Otherwise I either delete it or archive it with a suffix like "My db with Xfuncitonality.mdb"
Sorry can't help keep track of different versions.
What I do - when I've got an important database is to set up a table within the database, and use that to keep track of changes. I normally stick a form as the front end, and track changes to the different objects (forms etc). I have also writtent a database of databases which keeps tracks of versions (always give a database a version number). This way it's possible to look in a simple Access database to see what version3 has that version2 doesn't (it works perhaps!).
the problem on a live database is while you make the changes on the copy users can still enter new data to live database. you should either somehow make proper changes in your modified copy about new/deleted/modified data in live database, or you can just import tables from live database.
Unless modification is about structure of an everchanging table in live database, second option is what I go with it. I usualy take database offline at weekends for structural changes on the table level.
Last edited by ghozy; 09-24-04 at 09:34.
The database I use to modify and things like that is my "catch-all" because I keep old reports, queries, and forms in just in case I have to re-use a functionality that I built in to one of those old forms. Then I just export the objects I've updated. For the project I'm working on now, I really don't see the need for version numbers. I'm working on it for one company and it's a continual work in progress until it's the exact way they want it. If I were selling copies of it, it'd be a different story.
But it seems as though everyone does a lot similar to what I do. Basically, that's just keeping manual track of things. The thought about designing a form to select which object you're working on is a good idea, Ryker. Now, I just have to decide if putting the work into designing the code for that form would be worth it.
Thanks for all of your help guys!!! Anymore suggestions and I would be glad to hear them!
Im in the area of plateform releases of a MIS in access for education at present.
To do the updates (assuming that you are not trying to sort a corruption) I have the last version released as the active working DB in my machine.
I transfer all the data from the enduser to that (may seem a long process but, it works for me) I then have the changes to make for the next platform i rename that database ~name_rebuild_next version number ( 1.4 now 1.5)~
I make the new changes, test it with the most updated datasets.
If the changes are tested, work and all is well with the world then I will inform the end-user that the plateform will change at a time on a date.
All the changes made are recorded in a small school type note book set aside for that particular database. That way, each page that contains the changes to that plateform have the plateform number on the top of the page.
I also keep the previous plateform and the active plateform - just incase i need to go back to a version (we all make mistakes) plus it helps to know ho you got to where you are
just an idea, but it works really well for me and I dont had have many problems this way.