List View of Related records is very SLOW!

[Dali]

I'm displaying a list view of records using FM 8 client which connects to FM 8 Server over internet. If in the list view I display the fields that only come from the layout's table everything is fine...but as soon as I display a field from a related table the speed goes down significantly. Why is filemaker handling this so badly? Is there a way I can optimize client or server to fix this problem?

[Ender]

You might start by telling us about your server setup, client setup, and network speed.

Is the problem with all fields, or just some (unstored calcs maybe)?

If the hardware and software is robust, something that could be a culprit is duplicate or missing File References. Is this a converted solution (from FM6 or below)? In your File Reference list, do you see duplicate references to the same file? In the File Reference definition, do you see multiple paths listed.

[Dali]

FM Server 8 is running on a Dedicated Dual Xeon 3.0 GHz, 4GB RAM, 3x75 GB SCSI (Raid 5), Windows 2003, 100MBit Dedicated Network. There are no issues with file references and the solution was built from scratch in FM7 developer and then carried on to FM8. We tested multiple clients all on at least 1.5MBit/s connection. The test were made on regular text fields. We ran the optimize and compact tools as well, but there is still a significantly visible reduction in speed when the list view is displaying a field from the related table (again, a simple text field). Basically, as long as I display the fields from the layout's table everything is fine, but as soon as I display any field from any related table it takes much longer for FM to display rows...about half a second per row while in the prior case it draws an entire page almost instantly. This was tested with other tables and fields and always the same result. All client machines are quite new/fast machines, there is no problem in hardware whatsoever. It just seems like that filemaker is doing a poor job at pulling data from related tables.

[Søren Dyhr]

Do you utilize calc's based on global fields to control which data to usher into the portals shown?? How many primary keys do you generate. While it not is absolutely wrong to do so, is it not fully embracing the relational model filemaker as tool subscripe to or uses.

If a global fields measures can be quantizised into say integers, are you missing a table between your data and the way you browse it, a table containing indexed and stored data, so you needn't bother the calculation engine to deal with the re-evaluation of the keying.

Read this thread:

http://www.fmforums.com/forum/showtopic.php?tid/176396/post/204083/hl//

You might argue that the vast number of almost empty records is a waste, then pick the solution Comment made for testing the two approaches against each other (although his attempted conclusions tries to lead us elsewhere due to the testing environment he had availiable) ...and do me a favour, if posible do it over a WAN'ed connection, and it becomes clear why a prefab layer JMO originally suggested is the best!

--sd