Multiple accounts w/ONE database (*adb)

[Lowell Wardlow]

using A5v4.5

I have searched and have found references to the above, using "shadowed" tables, but can no definitive discussion as to how
to accomplish this.

I have (4) large clinics for which we do Medical billing, and keep
the entire system for each in a separate directory.

What I want to accomplish is to have ONE adb/database which
will reference the data only from one of the four sets of tables.

Any pointers or discussion wold be greatly appreciated. I am getting
tired of maintaining multiples of the same database.

Thanks for any help.
Lowell Wardlow

[Tom Cone Jr]

Lowell,

Others will chime in to correct or extend my comments but here are some ideas for you to chew on.

1) If you move the tables & sets into a single folder you'll have to rename them if you want to continue to use separate tables for each clinic. Consolidating the tables into a single folder using a single ADB would reduce the maintenance for all the global scripts, functions, and operations you've got on the Code page of your control panel. However, it would not reduce the maintenance chore for layouts based on tables or sets. If you redesign a report, you'll have to do it for each clinic separately, just like now. Why? because these layouts are saved in the table and set dictionaries, and you've got separate ones for each clinic.

2) To reduce maintenance further, consider using single tables and sets to hold the records for all clinics. You'll need to change the table structure to include a clinic identifier field of course, but then you'd simply arrange to filter the tables and sets when you want to work with a single clinic.

-- tom

ps. you've posted to the wrong forum. This is for vers 5 of Alpha Five.

[Bill Parker]

Hi Lowell,

Herre is the approach I take with a customer that needs multiple copies of the same database.

Program updates are done to a single version of the database. To apply an update, dictionary files are copied to each directory.

Each database has a different name, titles, etc. Those are kept in a "Parameters" table. In forms, the variables from the Parameters table are shown rather than having a text object. For example, instead of "Medical Lab 1", the title of a form would be the variable var->Title, which is a field in the Parameters table. This variable can be a calc field on the form that does a lookup to the Parameters table, or it could be a global variable initialized in the autoexec script.

My customer has different forms that might be used as the "main" form. So there is Parameters->main_form that stores the name of the form to open. I created a field rules lookup with the list of possible choices so it would be entered correctly.

The one maintenance problem is that the customer creates reports on one table in each of the systems. I don't know what new reports have been creatd where, so when I send a dictionary update I do not include that table. There are more sophisticated methods for doing a partial dictionary update.

In all, this application has 28 parameter fields that customize the system, even alowing the forms to have different color backgrounds so it is easy to tell the different copies apart.

Bill.