>In my previous job we have separate databases for Lookup tables, Support tables. We also splitted data by state, e.g. we have MA.dbc, RI.dbc, CT.dbc and NH.dbc
>
>At my current work we have one huge database with lots of tables. Even stage tables are included into the same database. I would probably separate stage tables from the work tables to different databases.

I have done this sort of splitting only once - but that was back in 2.6 and we were really pushing the limits of Fox and the network then. I had split the patient's archives by year of birth, but that was just to reduce the amount of data pulled over the network.

In your opinion, is there an overhead when there's many tables in a dbc? I figure VFP reads one table at a time from it, and since the dbc is just another indexed table, it should get the data very quickly. If you have multiple dbcs, it should take some time to run whatever code there is to select the particular dbc to which the table belongs, and each dbc would need to have its own buffers. So, each way has its ups and downs. I expect the speed gain (if any) would be marginal, so the reason may rather be in the ease of coding, rather than speed.

So, I'd like to hear your experiences, since you've done both.