Relations are driving me crazy...

[R2D2]

Hi !

I just cannot understand why this portal doesn't work:

I have 2 tables and a relation between them:

gAnnounced = cStatusAnnounced

and

cUserID = tUserID

In gAnnounced there is data "Announced" and cStatusAnnounced also contains "Announced". Both tables present UserID's correctly.

gAnnounced is global

cStatusAnnounced is calculation based on other input

cUserID is unstored, based on "Personnel" table

tUser is a lookup from "Personnel" -table

In portal based on that relation still shows nothing. What's wrong with this ??

[Søren Dyhr]

No unstored fields are!

The global has to be primary key, and a calc'field a relation away can't be expected to hold a value until attempted rendered via the layout the global which it's shown upon.

The desired virtues would in my humble opinion only work, using Ugo's method....

http://fmforums.com/forum/showpost.php?post/224848/

http://fmforums.com/forum/showpost.php?post/161053/

http://www.fmforums.com/forum/showtopic.php?tid/171550/fromsearch/1/hl/freshen/tp/0/all/1/

http://fmforums.com/forum/showtopic.php?tid/193847/post/284053/#284053

--sd

[R2D2]

Yes... That is something I was secretly afraid of. Now I have to start thinking, how to get around it. :-/

Thank you - again, Soren !

[Søren Dyhr]

Ugo has made the thinking for your ... why force your gray cells too?

http://fmforums.com/forum/showpost.php?post/266487/

--sd

[R2D2]

Uh oh... It is always very hard to figure out how to implement the solution to my problem.

[Lee Smith]

Ugo didn't post to the Thread you Linked.

Did you mean Fenton?

[R2D2]

Ok... If we come back to this problem. How would you suggest I should make this work ?

This solution is used in multiuser environment, so cUser should be "unstored" (or should it ??). How then I can make relations between tables based on cUser ?

I'm sorry, if this is very newbie -question...

[Søren Dyhr]

Eventhough Fenton made the template true however is it upon Ugo's discovery, you can trace it to here as well:

http://www.kevinfrank.com/download/repeating-lookups.zip

--sd

[Søren Dyhr]

I would say it would be hard to circumvent the need to repeat the TO and to have a record ID which obviously should be indexed to work as foreignkey ... since the TO is repeated should the calc reside in the leftmost if the flow is the latin reading direction getting a copy of the records ID if the condition is meet and NIL if not, and the relational querry would work!

--sd

[R2D2]

So, one, but very clumsy option, is always copy-paste current user to a global text -field in different tables and use it as a key field ?

There must be more sophisticated methods too.

[Søren Dyhr]

So, one, but very clumsy option, is always copy-paste current user to a global text -field in different tables and use it as a key field ?

So where did I say something allowing you to interpret it like that? I would never suggest copy/paste since it tampers with the users clipboard, further more would first turn to scripted queries when relational ones are exhausted.

The problem here is that your description of the problem is too abstract, what is required is a context/purpose without any fields declared ... something like a person who logs in should be able to see what kind of personalised data and why?

--sd

[R2D2]

No, you did not say that copy-paste would be the answer. That is the only option, I have left in my mind.

I use UserID to identify users. UserID is different than persons name. In many tables I need real names and those are fetched thru relations from Personnel table.

In this portal problem UserID is used to identify the current user (Get(account name)) and I try to match it's relational data (i.e. Real names) in other tables.

[R2D2]

Actually... Problem solved.

Now, when less whiskey in my head, I relooked all the fields again.

That cUser -relation worked all the time, but behind that cStatusAnnounced -calculation was one unstored relation and that caused whole thing to collapse. Now it is solved in a script step (Set Field), so that unstored relation is bypassed.

Thank you for good advice anyway !

[Søren Dyhr]

Relations as well as valuelists refuse to work, when an indexing issue arises, and with the introduction of triggers have the gremlins moved elsewhere... try to investigate this:

http://www.kevinfrank.com/download/2009/dwindling-value-lists.zip

--sd