Jump to content

Relation works different in different directions


David Holmberg
 Share

This topic is 5696 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

This topic is 5696 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.