Portal filtering!!! Oh, no!

[Slater]

Hi Everyone,

My question is about producing a portal, which filters out all but one particular type of entry in a field, but still allows data to be entered via the portal - as if the filtering wasn't there ...

kinda similar to LAGirls enquirey just v recently - but not similar enough, i think, as the answers there don't work for me - or answers elsewhere including the samples file either.

What i've got:

parent: PEOPLE

child: CONVERSATIONS

1 (people) to many (conversations) relationship (via ID_PERSON)

So PEOPLE file has in it:

ID_PERSON

NAME

and CONVERSAITON file has in it:

ID_CONVERSATION

CONVERSATION_SUBJECT

ID_PERSON

There are other things, but they're not concerned here (like address etc).

Linking them (how i've always had it) via the ID_PERSON ensures that only the conversations with that person come up in the portal. If i want to enter a conversation, i can do it in the portal and i don't have to go into CONVERSATION.

The problem is when i decided that i wanted one portal to show only one kind of conversation, and still be able to enter things into the DB via that portal.

Tried a calculation field where they combine the two (ie:

new field IN CONVERSATION: CALC_C=

ID_PERSON & " " & "news" if i'm looking to only show the "news" conversations

new field in PEOPLE: CALC_P=

ID_PERSON & " " & "CONVERSATION_SUBJECT"

and then the relationship is based on the calc field, ie:

CALC_C :: CALC_P

All good, and it works:

the portal shows only the "news" conversations for that person, goto another person, and the portal no longer shows it (cos it's not for that person).

BUT, what i can't do is input stuff into any field via that portal ("the relationship is not valid and must be corrected before this field can be modified" - something to do with indexing maybe) which, for me, is no good.

make sense?!

If you've got any ideas, i'd be most gratefull as i'm running round in circles!

Thanks,

Slater

[-Queue-]

Do you really have quotes around CONVERSATION_SUBJECT? I'm assuming you don't or else the filter wouldn't work, since the quotes signify text and not a field name.

I don't believe you can auto-create a related record in a filtered portal due to the related key being a concatenated calculation of other fields. It would have to set both the ID_PERSON and CONVERSATION_SUBJECT fields in order for the calculation to populate and establish the relationship. I think this requires scripting the creation of a new record in the related file and setting the related fields that comprise the calculation.

[Ender]

In order to use a compound key relationship for record creation through a portal, the compound key on the match side must be a normal text field. You can then derive the PersonID and Conversation Subject from the the compound key:

PersonID = leftwords( PersonID_ConversationSubject_Link, 1 )

and

ConversationSubject = rightwords( PersonID_ConversationSubject_Link, WordCount(PersonID_ConversationSubject_Link) - 1)

However, this does preclude you from using some other portal relationship for record creation in this file. If you don't like this, then you could use globals in the Person file as data entry fields, then script the creation of the Conversation records using the global data.

P.S.: One nice thing about FM7 is the ability to have multiple compound relationships to a table, and allow creation of related records through any of them.

[Slater]

Hi Queue

Do you really have quotes around CONVERSATION_SUBJECT? I'm assuming you don't

yes, you're right, it was just a typo in the post.

Thanks for the explanation ... it makes total sense.

So, i could make a button to:

create a new CONVERSATION record

then fill certain fields, via info from the current PERSON record

go back to the CONVERSATION record,

then i could edit the contents, ie fill in the details

I'm now smiling, unlike the weather here in grey old London!

thanks so much for your help,

Slater

[Slater]

Hi Ender,

In order to use a compound key relationship for record creation through a portal, the compound key on the match side must be a normal text field. You can then derive the PersonID and Conversation Subject from the the compound key

Thanks, i can understand that - tho it did take a few mins!

PersonID = leftwords( PersonID_ConversationSubject_Link, 1 )

If i was to derive my PERSON_ID from the compound key, it would, amongst other things - as you say - make some fields in my DB complicated / not work, because i've got a fair number of scripts and fields that use / rely on the PERSON_ID field.

You mentioned that FM7 would allow me to do these kinda things?

I seem to be cursed with FM upgrades - everytime i buy one, a month later the next version comes out! So i might just wait to be first in the line for FM8, unless that's gonna be in 2010.

Thanks again for your help, most appreciated,

Slater

[Ender]

Even though your PersonID field becomes a calc field in this case, the other fields that refer to it will be fine. To convert your existing records involves creating a temp text field to hold the PersonID & " " & ConversationSubject key until the fields are changed.

[Slater]

Thanks Ender,

got it sorted with a couple of scripts - so i'll probably leave it and not go opening up a can of worms!

have a cool weekend!

Slater