Physical Database Configuration

BrianP03103

There are several problems we have experienced and others I forsee with the current physical configuration of the database.

Previously, I set up two database entities. The first one held the software and most of the data. The other database entity held the pictures.

The problem experienced with this configuration was that, in spite of a clear field on the main menu for (re)linking the two databases, some just could not get the concept and had no end of problems getting the two to work together.

The current configuration uses one database entity, containing all of the software and most of the data. The pictures are contained in a hierarchy of file system folders external to the database entity. The database references these files and is sensitive to their physical placement.

The problem this time revolved with people physically relocating the database entity and not maintaining the proximity of the referenced picture file hierarchy. Of course, all of the pictures apparently went missing all of a sudden.

This is almost the same problem as the first configuration, linked stuff gets misplaced by the user and required connections are broken.

Now there is a new issue. What to do if there is a software update. With either of the two prior configurations, exporting the data from the old database and importing into the new database would be required.

Given the track record of a number of the users in our test group, this is even riskier and less likely to succeed than either of the two previous physical configurations.

Obviously, it is inadvisable to at all depend on the technical capabilities of the user(s) in maintaining the database. I would like to think that everyone was at least capable of handling the equivalent of a "file open" dialog, similar to what was required by the first configuration, but I don't know.

The most bulletproof and foolproof configuration I can think of is again two database entities. The first would contain all of the software but no data. The second would contain all of the data, including pictures.

This *would* require relinking the two databases whenever they are downloaded or relocated, but I can think of nothing safer. This would also allow the first database entity to be replaced in its entirety any time there is an update, without disturbing the contents of the of the second database entity (containing user's data and pictures).

What do you folks think? Does anyone have a better suggestion?

Regards,
Brian

__________________

Advertisement

carmi

Hi Brian,

In my humble experience the two databases is the best solution.

The user's data and the user's pictures must be a separate database.

As I see it, you should have at lest two databases, one for the program data and pictures and one for the user's data and pictures, so you can upgrade the program and/or the program database separately

__________________
Shalom (Peace),
Moshe.

Colors are an optic illusion of light – As viewers for the bonsai creation. M.S.C.

PatArizona

G'day Brian...

I think you've got it covered with the TWO Program.

Just don't forget ACCESS RUNTIME and hope that MicroSoft doesn't pull the plug on that one.

At my age, seventysomething...I have no desire to take on ACCESS, in all it's glory.

Pat

__________________
BONSAI isn't about surviving in a storm, rather, how to dance in the rain.
THE ONLY WAY: Always remember, and don't ever forget, that whatever you read here is not cast in concrete... the intent of any advice is to help. In no way should you feel that I’m saying that my way is the only way…heaven forbid! I've seen far too much of the "my way or the highway" attitude in bonsai as well as in other areas of life.

kcpoole

Hi Brian

2 Db's is the way to go and you should just hard code the "Application" DB to look for a specific file name in the same directory as it resides for the "Data" DB.

This way you can say that if the pichtures/data does not appear in the DB, then check that the other file exists in the current directory as the Main DB file. ( you could even check it exists on startup and give an error if not present.

If it is left up the the users to locate and find the correct file then problems will ensue.


Ken

__________________
When engineers work out how to make something Idiot proof, humanity invents a better Idiot