>hi all... this is my first message and i am looking for many happy returns.
>
>I am finally switching to Visual and would like to convert my 2.6 application. As I have learned, rewrite is the only practical solution here. However, my research has not provided a direct answer to my questions. My application is used in healthcare (home infusion pharmacy) and includes the whole gamut of free tables. Patients, Physicians, prescriptions, purchase orders, accounts receivables and on and on.
>
>My questions:
>1. Should I convert all of my free tables to a database?
>2. Am I right to assume that there will be only one database for the entire project.
>3. Or is there a standard to determine if and how to assign the tables into various databases?
>
>thanks in advance
>
>Mark Kliethermes
>Clinical Pharmacy Systems, Inc.

Hi Mark


1. Should I convert all of my free tables to a database?
You don't have to. But if you want to use primary keys, create permanent relations between tables, use longer field names, use additional table properties, setup automatic referential integrity and a few other things, you will need to bring those tables into a database container.

2. Am I right to assume that there will be only one database for the entire project.
No, any one project can have any number of database containers associated with it. Any one database container can appear in any number of projects. However, a table can only appear in one database container. Furthermore, if you want to set up relations between tables, since those relations are stored in the database container, all tables involved in the relation must be in the same DBC. This means you will most likely group similar related tables into a single DBC.

3. Or is there a standard to determine if and how to assign the tables into various databases?
As mentioned above, the decision on how to group tables into different databases depends on the relationships between those tables. If the tables are related, they should be in the same DBC if you want to use permanent relations or built-in referential integrity.

Mike