Me again, still playing with remote access techniques for an .fp4 database served by FMS3. Based on my observations when using larger database files, it appears as though FMS doles out an entire file to a client, and then returns alterations to the server as they are made.

Is this assumption correct? Does this behavior extend to subsequent FM versions? If so, it seems like a strong argument for pruning unneccessary content out of databases that might be served this way...

Thanks,

--Chris

I don't think that FMS doles out whole files. In fact I don't think the client works this way either, otherwise FMP file size would be limited to the available RAM.

Even back in FMS 3, some functions like indexing are done on the server, not the client box. Subsequent versions have additional optimisations. FMS 7 probably uses a completely different database engine to 5.5 and earlier, and it screams with unstored fields.

Eureka! That makes perfect sense -- and explains why FMS can host so much data with such paltry allocations of RAM.

Perhaps I'm confusing the layouts with the data? I made "clones" a while back that were as much as 756kB while containing zero records.

My latest (ignorant) hypothesis is that when a client opens a hosted file, the server returns ALL the layouts as well as one record (the first one?) to populate the layout that is displayed by default. This should be easy to test. I'll split a bloated existing database into [layouts without records] and [records without layouts] and compare the responsiveness.

(It's unlikely I'll ever become an expert at this stuff, but it's still fun to try.)

Thanks again!

I don't think it returns all the layouts either -- a client of mine made a file with over 800 layouts, and it's take a wile to download them all.

Graphics on layouts significantly slows things down. What we call "native" FMP graphics (lines, rectangles and buttons drawn using the FMP tools in layout mode) are the fastest and most efficient. Bitmapped graphics are less efficient. I'll guess that Postscript graphics and pdfs are probably the worst.

I personally keep non-native graphics to an absolute minimum (very often using none at all) and even go so far as to keep native graphical objects to a minumum too.

My little experiment corroborated your last reply. Whether dealing with 756kB of layouts, or 53k records, the responsiveness was virtually identical. Of course, this was with DSL on the server end and a cable modem at the client -- dial-up clients may see a more pronounced difference.

We still have a lot of housekeeping to do, with dozens of layouts and as many as 119 fields. I suspect there is a lot of overlap/redundancy/scrap in there. But based on what I've seen, it shouldn't keep us from forging ahead with this project. Luckily, the layouts were designed with native FMP graphic tools, so that element, at least, is sort of optimized.

And, still more enlightenment with regard to the performance penalty that occurs when FMS under OS9 is not the foreground process. I had read about this, but what was surprising was just how MUCH faster it ran when left in the foreground.

--Chris