URGENT! Max # Fields? SLOW Web delivery??

[Paul.Stoll]

Hi All,

I need some urgent help regarding FMPro v4.1v3 on Mac OS 9.1 using Web Companion.

We have 33 open databases (with several related fields) and we're trying to pull data back to web

clients form one particular database (which is identical to 29 other databases in structure), which has

over 775 fields of data, most of which are summary fields (i.e. we want to do on-line "statistics" of

user-entered data).

The requests take 2-3 minutes, and often fail with error -50.

Has ANYONE built databases with more than 750 fields and successfully parsed that data back to

web-based clients using web companion? And if so, was it fast?

HELP! I was meant to have this system on-line on the 5th November, and we're just getting worse

and worse...

[Vaughan]

I'd suggest the problem is the summary fields, rather than the number of 750. Unfortunately I have no solution, having avoided summary fields is wedb solutions.

[dspires]

Vaughan is right, summary fields will KILL performance.

I had one application that needed summary fields (on a monthly basis) and what I did was created a related (relationship by month/year) database that had the summary fields. Every month I would add a new record in that database which would summarize and store the results in the single record.

[Anatoli]

On NT4 the FM 5 Unlim. is in such operation 5-7 times faster, than v. 4.

I guess on Mac it can be 2-7 times faster as well. That will improve performance dramatically.

What is the difference between processing time in FileMaker and FM with WebCompanion?

[Vaughan]

One of the problems might be a TCP/IP or web timeout or something, if the summary fields takes 30 or so seconds to calculate. Browser calles to WC, WC to FMP, FMP calculates for a minute, browser gives up waiting and times-out.

[Paul.Stoll]

Thanks to all for your advice and help. We've reduced the # fields from 775 to 170, and now do the stats analysis client-side in Javascript - reduces search time on server to just seconds, and even the local client-side processing is blistering fast. So we broke FMPro, but the work-around solves our problem on this little project - for FREE and in less than 10 days...

So thanks again to all, and hopefully you'll all be equally kind if we stumble and fall and need more help in the future, and hopefully one day I might be able to repay your kindness in kind. Nice to part of such a helping community!

[Garry Claridge]

You may also want to check if one of the databases is not corrupt. I have had this sort of behaviour from a corrupt file. Recreating it fixed the problem.

However, moving the summary data into a seperate file sounds like a good idea.

All the best.

Garry