Hi group

I have a project for a larger group than what I'm used to, probably with
a server setup eventually instead of peer-to-peer networking. I'll be
working with Filemaker 5 or 6. I know that there are Filemker white
papers for server best practices, but if I remember well from looking
some time ago, they cover mostly technical aspects of the server setup,
not design of the files themselves. So I just would like your advice on
some approaches that may have an impact on performance or be inadequate
in a server setup.

For instance, I usually apply a "separation model", even in versions
prior to Fielmaker 7. I have data entry files, and when submitted (and
validated), the data is channeled to the "real" data files. To do this,
I use a script that loops through the new records, set globals and
triggers new record creation scripts in the target file. Does that sound
reasonnable in a server environnement? I suppose that export/import
would not be possible anyway, but maybe there's another way?

Also, for viewwing the data, I wonder where best to create the layouts.
For instance, if I want to see the inventory related to a provider, I
can use portals, filtered portals in a tabbed interface in the providers
file. But I still have to create print layouts in the inventory file
with reverse relationships. And maybe the viewing layouts can also be
there (masimum number of rows is sometimes a problem with portals, not
just for printing). They can all be done as reports or in browse mode
(going to related records and displaying reverse relationship info in
the header). Finally, the viewing layouts can also be in other interface
files, using globals and portals to see the related data. But what would
be the best approach for a larger network? As tou can see, I tend to
separate things more and more in different files, but I wonder if this
is wise as I work on larger projects. Do you think it best to limit the
number of files and keep it as simple as possible?

Last point (for now...), I tend to script as much as possible, partly to
avoid calculations. Sometimes, though, I would like to keep the
calculations also, even I don't use them in relationships or for
display. For instance, I may set a status field with a script, but I
would slike to keep also a calculated result. With it, I can create a
"maintenance" script to find records where the set value doesn't reflect
the calculated value. Or maybe I should avoid these calcs also, even if
I don't use them in regular layouts?

Thanks


Marc-André Paiement