I would use SQL Server and not worry about fragmenting the database. You are causing yourself a lot of grief for no return by having separate databases. You will have to make your application open different databases, and also have to maintain all of the separate tables 1)backup, 2)indexes, 3)etc.

I would just mark the records with the branch id, and have one database. If you don't, reporting will become a nightmare, maintenance, etc.

Saying that you are not going to SQL Server because you don't have time to learn it does not make good business sense. You are talking about spending an inordinate amount of time trying to make VFP be the answer to the problem - when SQL Server will handle what you are proposing with little effort. In a couple of weeks, you could immerse yourself in SQL Server - read books, etc and become proficient using it. There are consultants available to help - the people here will help, etc.



>Hi,
>I would like to get some advise on database design.
>I am designing inventory control, which will be used by 10 branches. Each branch may has 5-10 sales persons. The application should take care of stock for every branch and every sales person and all data will be sendt to HQ at the end of the day. Therefore, the number of records will be dramatically incrased.
>
>To prevent too large size of each table, I am tring to "fragment" my database. I am not considering SQL server at this moment because I am lack of time to learn it. Here is my design:
>
>1. One main database will contain all master tables such as item, sales person, debtor ...
>
>2. Secondary database for each branch that will be placed in different directory. It will has tables that used particularly for each branch like invoice, stock, transfer ...
>
>Does the design make sense?
>Any comments?
>
>However, I found that, I cant use integrity referential in my case. Any workaround?
>
>Pls advise. Thank you