We're trying to do remote hosting with Calendar Complete. We've already divided the file into the separation model and it works fine on our local in-house server [macMini with FMp sa 10 with FMp 10 clients] We've now uploaded the files to two remote hosting services as a test. In both cases it takes upwards of 5 minutes to open the files and is extremely slow moving between layouts. We've tested a much simpler file, Postcodes with over 16,000 entries, and that is best described as very fast although it does not have globals or complex relationships. As part of the testing we uploaded the original Calendar Complete file unmodified in any way and it takes over 2 minutes to load. In both cases once a layout has been 'visited' it seems to cache and is quite quick to return to it but going to a 'new' layout takes an inordinate length of time.

Have we struck a brick wall? or just missed something in the implementation. Other solutions I have seen seem to work quite well using this model but most of them are quite a bit simpler.

Any thoughts appreciated.

Hi Petern,

I think what you're seeing is pretty normal, though it certainly depends a good deal on your remote host.

I just opened a customer's file remotely- they've heavily modified a version of our calendar and use it remotely- it took me 47 seconds to open the file. (FileMaker 10, and they open to the Contacts layout by default. I also click on the screen as it is drawing to "encourage" it. FWIW, that file is hosted by http://www.filemaker7hosting.com).

And you're also right that once it is open, some things move a lot more quickly. Some of the more intense screens will be slow over a remote connection, however, especially the fancy week view and the scheduling view. Simpler files (even simpler layouts within Complete) are definitely faster.

Working remotely, even on a slightly faster connection, would drive me crazy, but some of our customers are very happy with it.

One separation trick you could try is to keep the interface file local and host just the data file (don't know if you're doing that already). To do this you need to make sure that the data file doesn't have any file references to the interface file or call any scripts within it.

If you feel like trying that I'd be interested to know what you think that does to the speed.

Hope that helps,

John

John,
Thanks for the quick reply. Unfortunately I think you're right on most points. We've tried 2 separate hosts with only marginal differences in results.

We've tried almost everything we could think of with only very small gains.
Local layouts with data only on the remote host gives the best result and is almost useable but of course the client will be the final arbiter.

The problem seems to revolve around relationships, globals [to some degree] and centrally stored graphics. We've eliminated scripts, tables and text/number fields, as we imported them all (700 scripts and all your tables) into a simple hosted file and even with broken relationships everywhere, that file still opened in 8 seconds. The local layout file opening the remote data file is the best...opening in less than a minute and then working [nearly] well.

A different client has an old hosted FMp v6 solution - over 20 files but almost no relationships - it's fast enough for daily use but, of course we can't go backwards!

Hope our experience might be of value to others.

PeterN

peternew wrote:A different client has an old hosted FMp v6 solution - over 20 files but almost no relationships - it's fast enough for daily use but, of course we can't go backwards!

Hope our experience might be of value to others.

The hosting provider John mentioned above states on their Website:"FileMaker 7, 8 and 9 offer near-LAN speeds when the file is accessed over the Internet". Does this mean reasonable speed over the internet may not be expected using FM versions 10 and 11? Or is this a tribute to the relational data model?

With Calendar Complete we have to (and want to) use current FM versions. And we DO need reasonable speeds over the Internet without having local copies of the UI file everywhere. So what is the best practice to achieve that?

Regards
Franz