Creating record in portal

[jodibee]

Hi All,

Merry Christmas and all that. I have a problem with a portal that I can't work out. My portal is showing records correctly, but does not allow me to create a new record in the related database via the portal even though the relationship is set to allow this. The error message I get tells me that the relationship is invalid. If it is invalid then why is it displaying existing related records correctly?

My match fields are both calculated fields and have the same calculation, which is:

If(Study = "AMFS", Individual ID & "-" & Family ID & "-" & Blood ID, Study & "-" & Individual ID & "-" & Family ID & "-" & Blood ID)

Does anyone have any thoughts on what is going on?

Thanks in advance.

[John Caballero]

Hmmm...I saw a post recently (by ESpringer, I think) which said you can't use the create related records feature if the right hand side of the relationship is a calculation.

[ESpringer]

Indeed, I think I pointed that out recently... Database-like memory, John

One work-around is to make the RH key into a text field, sometimes with a "do not modify".

Sometimes, you can just copy the existing calc and change the data type in the remote DB from calc (text result) to text (this preserves the existing values), then paste the calc into the auto-enter calc from the Options... in Field Definition.

But in your case adding the "auto-enter" calc aspect to the field's definition won't add any functionality compared to being a plain text field.

(It's not necessary for the portal process because when you're creating records from the portal, it wouldn't look at that auto-enter calc anyway, because it knows that the key field has to read just like the one in the home db. It's useless in its own db because if you were to try creating records from the actual file, now, the auto-enter in this case would at the moment of record-creation be drawing on blank fields. So you might as well not make it auto-enter anything at all.)

If you think you'd *usually* create records via this portal, then just making the remote version of the concat ID into a text field is the way to go... you could turn all the *component* fields (individual ID, etc.) into calculations which peek into the brute-text concat key and pull out or construct the relevant bits based on the concat ID.

After this change, if you then go to work directly in that RH db, data entry would proceed by typing in the whole concat field, (rather than working from the components and having the concat calculate itself).

I suppose you might instead be able to preserve basic-field data entry via a concat calc (which is NOT the RH key), and a lookup which puts that calc into the non-calculated RH key field...

(Do you need all those fields to be separately articulated in the remote DB, or is it "essentially" a child file?)

[jodibee]

I have been thinking about this further...which is a chore on a VERY hot day. Yes I do need the 3-4 identification fields as it they are an integral part of our sample identification as we can have multiple blood id's for the one individual and we are monitoring samples for multiple studies. I think the way to get around this is to have a command button with an attached script that dumps the current Individual, Family and Blood ID values into their corresponding fields in the RH file, that way the p_calc_key will be valid in the RH db and my users can go on creating their records in the portal. As the relationship stands it is trying to establish the relationship with an empty field. Will give it a bit of a test and see what happens.

Thanks for the input guys!