Help organizing DB's?

  • Thread starter Thread starter Lisa Reber
  • Start date Start date
L

Lisa Reber

Hi - this may be a dumb question, but I'm losing track
of my databases! I have Contacts, Inventory & Collections
and have different problems to solve or improvements to
make in each one. So I have Contacts, copy of contacts,
copy of contacts with DD changes, contacts new, etc.
My idea was 1 - don't mess up the master copy and 2 - keep
changes separated from each other. But I have a hard time
completing lots of the changes, so I end up making lots
of posts to different pages here. Of course, in a couple
months it seems to have gotten out of hand! Anybody have
any suggestions? Thanks!
 
Lisa Reber said:
Hi - this may be a dumb question, but I'm losing track
of my databases! I have Contacts, Inventory & Collections
and have different problems to solve or improvements to
make in each one. So I have Contacts, copy of contacts,
copy of contacts with DD changes, contacts new, etc.
My idea was 1 - don't mess up the master copy and 2 - keep
changes separated from each other. But I have a hard time
completing lots of the changes, so I end up making lots
of posts to different pages here. Of course, in a couple
months it seems to have gotten out of hand! Anybody have
any suggestions? Thanks!
Click to expand...

Actually, I suspect this is a common problem.

This method (usually)works for me.

I have a [Versions] table where I record a version number and brief notes of
the changes.
Each time I have a new working version to go out, I update the version
number.
I keep a copy of each version in its own folder named after the version
number, e.g.
c:\mydatabase\version99\database.mdb
This folder will contain front end, back end, and any other files it needs
to work.

Each new version gets archived to CD in a similar folder structure.

My working copy sits in another folder and I take temporary copies 'just in
case' as often as I need.
I give these temporary copies names like database04-04-30.mdb, so that I
know when they were made.
(The date format is so that they appear in the right order if there are
several of them).
(Yes, I know I could use the file creation date, but I might want to open an
old file to look at it...)
Temporary copies are strictly temporary and get wiped every now and then.

Will be interested to see some better ideas.

David
 
You can try:

1) create a folder for today date
2) copy the mdb file to it.
3) repeat step 1 for any major changes

That way, you can always go back one day or more, if you need to.
 
Lisa Reber said:
Hi - this may be a dumb question, but I'm losing track
of my databases! I have Contacts, Inventory & Collections
and have different problems to solve or improvements to
make in each one. So I have Contacts, copy of contacts,
copy of contacts with DD changes, contacts new, etc.
My idea was 1 - don't mess up the master copy and 2 - keep
changes separated from each other. But I have a hard time
completing lots of the changes, so I end up making lots
of posts to different pages here. Of course, in a couple
months it seems to have gotten out of hand! Anybody have
any suggestions? Thanks!
Click to expand...

Have you tried Visual SourceSafe? It's ugly the way it works in Access 97
but it may be improved in later versions.
 
Sourcesafe works pretty good in Access 2k and XP - haven't tried it out in
2k3 yet.

Still ugly at times, but pretty good most of the time.
 
Thanks for ALL the replies! I have a vocabulary question
for David: What do you mean by:
"This folder will contain front end, back end, and any
other files it needs to work."
Thanks - Lisa
 
Lisa Reber said:
Thanks for ALL the replies! I have a vocabulary question
for David: What do you mean by:
"This folder will contain front end, back end, and any
other files it needs to work."
Thanks - Lisa
Actually, I suspect this is a common problem.

This method (usually)works for me.

I have a [Versions] table where I record a version number and brief notes of
the changes.
Each time I have a new working version to go out, I update the version
number.
I keep a copy of each version in its own folder named after the version
number, e.g.
c:\mydatabase\version99\database.mdb
This folder will contain front end, back end, and any other files it needs
to work.

Each new version gets archived to CD in a similar folder structure.

My working copy sits in another folder and I take temporary copies 'just in
case' as often as I need.
I give these temporary copies names like database04-04- 30.mdb, so that I
know when they were made.
(The date format is so that they appear in the right order if there are
several of them).
(Yes, I know I could use the file creation date, but I might want to open an
old file to look at it...)
Temporary copies are strictly temporary and get wiped every now and then.

Will be interested to see some better ideas.
Click to expand...
Click to expand...

Hi Lisa,

It is fairly common practice to separate an Access application into two
files.

To do this, you put your tables into one database file, e.g mydata.mdb.
This file is the 'back end'.

All the forms and reports then go in another file, e.g. myapplication.mdb.
This file is the 'front end', i.e. the file that the users open.
The front end will need to contain links to the tables in the back end.

Generally all the queries and modules also end up in the 'front end',
because
they are part of the operation, rather than data. There may also be some
tables in the 'front end', if these are required for operation of the
application,
but are not really user data.

Why go to all this trouble? That's really another topic, but it becomes
very useful
when you update the database (forms and reports) because you can continue
working with the old version until the new version is OK, and then simply
link
the tables. If you have several users, you can give each of them their own
copy
of the front end file, which can also have advantages...

When you modify the database, you will often find that it is only the front
end that
needs modifying. However, if the data structure needs changing, you will
also
have to change the back end. This type of change needs controlling even
more
carefully, because it might involve a one-time editting of the data, e.g.
separating
the data in one table into two new related tables, usually because the data
structure
was designed badly in the first place. Happens to the best of us from time
to time.

As for 'any other files it needs', this depends on your application.
Often there will be no other files. However, I have one application
where the user needs to keep data for different projects in different files.
In this case, we have one 'front end' file, several 'back end' files, and
an 'index' file, which enables the users to select the 'back end' that
they require.

Hope this helps.

David
 
Back
Top