My upgrade from 5.5/6 to FM8 being served on FMSA (using Blackbelt for
CDML, thank you FMPWebSchool!) has been completed successfully.

It was 80ish files that I had worked on for a few months to clean up
all the script differences, and 70ish users that I had to set up with
new client software and login files.

Now coming into FM8 I am aware that the new model is one of multiple
tables in one file. I am aware that I could do one of the following:

1. leave a single table in each file as I have now
2. Partially consolidate some tables together, such as invoices and
invoicelineitems for instance
3. Go all out and have 1 file with 80 or so tables

My concern with number 3, and even a bit with number 2 follows. I
currently might have dozens of scripts, a couple dozen layouts, and
dozens of fields in a single one of my files if it is one of the
"major" ones (customers, jobs, invoices, estimates, etc). In these
large files, it is hard enough today to find the script I want, or the
field I want, or the layout I want.

How could I possibly keep track if my entire enterprise FM system were
in one file? The fields would be separated into their own tables so
that would be OK, but what separates the scripts from each other?
Would I face a popup menu of 1000 scripts? Would I have to scroll
through 300-600 layouts? That would be ridiculous.

So it seems like FM has the capability now to use a single-file
architecture, but I don't think the UI to support it for large
solutions is there yet.

Thoughts?

"Paul Bruneau" <paul (AT) ethicalpaul (DOT) com> schreef in bericht
news:1178130728.022556.308130 (AT) u30g2000hsc (DOT) googlegroups.com...
Paul, we just had a longish discussing on the newsgroup about this.
That boiled down to partially consolidate. There are allways files that are
better outside the main application as well as files within the main
application. Currently I decide each time what I want. A file with tables
totally decicated to printing, a file for the gui and interface graphics
(Could be reused with other solutions) The main file with table for all kind
of (related) data, but my zip-code file remains on its own. I think you get
my drift and the last word hasn't been said on this.
It is all what you like best. And I think we agree that it is high time
Filemaker came with better tools for tables and script to maintain.

Keep well, Erik

On May 2, 11:32 am, Paul Bruneau <p... (AT) ethicalpaul (DOT) com> wrote:
Pretty much nail on the head.

Although even if they fix that, some separation would still be worth
it. When I update our systems, most major data files are in separate
tables, so I can usually avoid re-importing the entire solution, and
that saves a LOT of time (money).

Usually I replace a couple UI files that contain a big chunk of the
functionality, along with utility and work tables, but I only have to
re-import one or two of the real data files to deploy some new field
defs or field def changes.

I rarely have to re-import ALL of them, which you'd have to do every
single time in an single-file solution. Unless you make all your
changes right on the live system -- which really isn't practical
beyond fairly minor adjustments.

-cheers,
Dave