>Hi,
>DO you think store all tables in ONE database is better i\or seperate them into more?

For example, my largest vfp app currently uses about 35 DBCs, containing a total of around 5,000 tables and views (and always slowly growing, but with some DBCs periodically retired to archive status). This is a natural split, based largely on whether tables are related at all, and should be grouped together, and whether they will be archived as entire DBCS.

(On the other end, my smaller apps use 1 or 2 only DBCs. As Craig and Cindy said, it all depends...I might add that when DBCs get extremely large, they do get a little slower and more awkward to work with)

One other suggestion, in addition to Cindy's on using local view-DBCs, is to divide server tables/views up into at least 2, maybe 3 DBCs when possible, using the following criteria:

1) One DBC contains all user-updatable tables.

2) A *different* DBC contains only archived/lookup tables: readonly data. For these DBCS, you can keep them in a separate Readonly share/folder. This can reduce security needs, and any possible index corruption, etc.

3) Another category can be DBCs for data-sensitive tables, where you want to encrypt everything.