I'm currently running 9 solutions, for a total of 46 files served with FMServer 5.5.

Each solution have its own files (tables) and have some tables in common with other solutions.

Now I'm planning a migration to 7. But what would you do?

1. A single FM7 file containing 46 tables (one file for all the 9 solutions)

or

2. One file for each solution plus one or more file for the common tables?

...

More generally, developing in fm7, what is the best file-vs-table configuration?

What are the advantages of having related tables inside the same files and having them in separate files?

Thanks in advance,

Paolo

I don't think anyone can answer this question at this time. Both of your proposed choices are workable. Choice 1 may be the easiest for design, choice 2 may be the easiest to maintain.

A third choice is the separation model, which has a file of data tables, a file of business rules, i.e., calculations and reports and an interface file of layouts for user interface. In this model you could have all your data tables in one file, and have a Busness Rule file for each solution. You could also have an Interface file for each solution.

If you start with choice 1, you can break it apart easier than you can put the pieces together.

I would think that you should divide your solution into 10 pieces...10 file. 1 file for each solution and 1 file for all the common tables.

I am basically going foward with the concept of 1 file per solution, with a few exceptions like common table between solutions, extremely large tables in thier own file, optional modules in thier own file, web-accessible tables in thier own file, etc.

I have played with data seperation in FM7 and I am not seeing the point for the types of non-distributed/non-shrinkwrap solutions that I develop.