Relation works different in different directions

[David Holmberg]

I've created a relationship that doesn't work as I want it to.... (it doesn't work at all)

Table 1 Table 2

Name User (text) = Name User (text)

Text Season (global, text) = Text Season (text)

Text Rel (global, text) = Text Rel(calc, text)

Name Ski (text) = Name Ski (text)

Layout 1 shows records from table 1

Layout 2 shows records from table 2

When the data in the fields in table 1 & 2 are excactly the same:

Layout 1 shows no related records from table 2 in a portal

Layout 2 shows related records from table 1 in a portal

When the data in the fields in table 1 & 2 are different:

Layout 2 still shows related records from table 1 in a portal

... is there something with using a global field and a calc field in a relationhip, or is there something else I've missed?

Grateful for all your ideas

[IdealData]

Globals cannot be used on the child side of teh relationship as they cannot be indexed and relationships have to use fields that are indexed. You can, however, use a global on the parent side.

The calc field may also fall into the same category as it can be set not to be indexed, and cannot be indexed if it relies upon a global or related field in its calculation.

FMP issues warnings when creating the relationship, but I can't advise you if you change the field type or indexing on the key/index fields later.

[Søren Dyhr]

is there something with using a global field and a calc field in a relationhip, or is there something else I've missed?

Yes there is exactly as Mark says in his mail, the part you're missing is to recognize that globals are a bad habit, and you should facilitate your views with enough TO's instead, to accomplish the same things.

Are you really using the 4 rules mentioned here??

http://www.filemakermagazine.com/secured/541/GraphRules_full.mov

Further more should you consider Anchor Bouy, where the bi-direktivity deliberatley is avoided, again with more TO's

Please consider to read page 37-38 in this:

http://www.filemaker.com/downloads/pdf/FMDev_ConvNov05.pdf

A few points as to why consider such methodology:

Significantly reduces complexity of graph

Allows the relational structure of the system to be understood, to some degree, outside of the graph.

Naming is automatic and does not require a lot of thinking or discretion, except for the optional relationship meta-data (Descriptive Name).

TOGs are mostly layout-based which makes it easy to locate TOs on the Relationships Graph.

Works very well for large solutions

--sd