1. Add == to list of operators to join tables. The equijoin operator, =, is really >=. Example: consider two chemistry tables joined (with =)by the element_compound field. The first table has records in the order HF (Hydrogen Fluoride), Hf (Hafnium), and H (Hydrogen). The second table has records in the order H, Hf, HF. If I do a lookup from H in the second table to the first table, the record chosen is HF, not H! Having == available would fix this problem.

2. Stop doing so many screen refreshes when printing the current record; I count 5, which drastically slows the action.

3. When printing the current record, print the entire layout, not just the data (or at least have that option).

4. Have a debugger for the calculation fields and custom functions so a developer can step through the processing.

5. Be able to list the field order for processing on a layout, so that a developer can see if there is some "strange loop" slowing down the action.

6. Be able to graph data from a single record or selected set of records, from one or more fields.

Edited April 19, 200817 yr by Guest

The equijoin operator, =, is really >=.

I don't think that's an accurate description. If you do a lookup matching "H", the ONLY record to respond will be the Hydrogen record. I don't see what the order of records has to do with this either - unless you are looking up next lower/higher.

You WILL have problems matching "Hf", because the default match is not case-sensitive. In your example, you have to change the indexing language of the match fields to Unicode.

There are other ways around the problem with = in Relationships Graph. It is possible to sort the tables in the Relationships Graph and that's what I've resorted to doing for the time being. It's also possible to add additional constraints. But: honestly, wouldn't it just be easier to add == to the list of operators?

Which problem are you referring to? The problem you described in your original post des not exist. The "problem" of "HF" and "Hf" will NOT be solved by sorting the related records. All you can achieve by changing the sort order is that both "HF" and "Hf" will lookup from "Hf", instead of both of them looking up from "HF".

Filemaker uses the index to find matching records, and unless you change the indexing method, "HF" and "Hf" will be indexed the same way. This affects not only the relationship, but also value lists (try defining a value list based on this field, and you will see only one of them will be listed there), finds and everything else that uses the index. Changing the relational operator is NOT the correct place to fix an indexing issue.

On my wish #2 above I recently discovered that if I minimize the window before the printing and then restore it afterwards, I can shave many minutes off the time it takes to print the current record (particularly one with numerous calculation fields).