Some data on layout not writing

[donaldking]

Certain data in portal not writing to record:

Go to portal row [select;first]

Go to (primary key) field [Registrant::RegistrationNo]

Set field [Registrant::RegistrationNo = $$Reg_Nbr]

Go to (secondary key) [Registrant::RegistrationNo_Sub]

Set Next Serial Value [Registrant::RegistrationNo_Sub] (Did in layout)

Copy Record/Request

Problem: primary key wrote, secondary key did not.

This portion of file structure:

Registration

PK Registration::RegistrationNo

Registrants (1 - 4)

PK Registrant::RegistrationNo

SK Registrant::RegistrationNo_Sub (1 - 4)(max can not exceed 4)

[Vaughan]

Instead of doing the work in the portal, try doing it in the related table itself by going to layout based on the table, create a new record, set the data, then return to the original layout.

I don;t know what the Set Next Serial Value stuff is about: is it incrementing the primary key?

[donaldking]

Thanks Vaughan -

I will try the approach as you have suggested.

Yes, the Next Serial Value generates a unique PK and then a unique secondary within each primary key.

Should I Copy the related record prior to returning to the layout?

Edited August 27, 2008 by Guest

[Vaughan]

Why not use an auto-enter to generate the unique serial number for the primary key?

[donaldking]

I use auto-enter for the PK as it is never reset. But with each new PK, I want to reset the SK to 1.

Convention registration. Each registration submitted can contain 1 - 4 registrants.

[Vaughan]

There are some things you are doing that I don't think are necessary.

Firstly, I assume that the relationship for the portal has the "allow creation of related records" option selected, so you can create new records through the portal.

If so, there is no need to set the foreign key in the related record; FMP does that automatically.

Secondly, if you're wanting to create more than one related record, going to the first portal row and entering the information will usually just overwrite the existing related record. Not good. It's better to (in pseudo code)

remember the primary key of the parent record

go to the related table

create a new record

set the foreign key to the remembered primary key

set other data as needed

commit the record

return to the parent table

Regarding the "unique secondary" field, is this really necessary? Do the related records have to be numbered 1-4? You can limit the number of related records by counting them before running the new related record script.

Not having this sub-count field saves a lot of trouble. It's the kind of stuff I leave out. You can always number the portal rows with "@@" to make the numbers appear.

[donaldking]

PK keeps a package/registration together.

The SK is to ensure uniqueness within a registration - for meal and tour selections - also for door prizes. I can not use name for uniqueness for obvious reasons.

But I can use an incrementing number which would never have to be reset.

Yes -I set "allow creation of related records".

Thanks Vaughan

Edited August 28, 2008 by Guest

[Vaughan]

"The SK is to ensure uniqueness within a registration - for meal and tour selections - also for door prizes.... But I can use an incrementing number which would never have to be reset."

Yep. Keep everything as zero-maintenance as possible.