Portal Data to Portal Data (Master Record)

[James Steele]

Ok here a sample file of what I am trying to do.

In the Routing table it is a list of parts and in the Routing Data Table contains steps these are master files that are for initial building of the traveler tables. These are like MASTER RECORD for each part number.

The Traveler table get its the information first by typing in the work order pulling the Item number then based on that number it pulls routing header information from the routing table.

Information is changed in the traveler table it is not reflected into the Routing Table.

Like wise, once a traveler gets the information once from the Routing Table, changes to the Routing Tables do not modify the existing traveler tables.

I would like to know how to get the data tables to also do this copy or data dump from the Routing Data Table to the Traveler Data Table.

Any assistance would be helpful. I have uploaded a sample of what I am attempting for reference. Please feel free to modify it and repost any ideas.

wotest.zip

Thanks

James

[Søren Dyhr]

Disallow "Creation of related record" and make a button, that goes to the related records and issue a duplicate record step on the latest created record, and then return to the main layout.

To gather the step description in the main table use a recursive CF utilizing GetNthRecord( looking at the related data, but not as a lookup but an unstored calcfield.

--sd

[James Steele]

SD,

I do not think that we are on the same page, but I could be wrong.

Disallow "Creation of related record" and make a button, that goes to the related records and issue a duplicate record step on the latest created record, and then return to the main layout.

I have a master record that has header and detail lines and I have transaction records with header and detail lines. They both need to have the data cereated/seen through the portal. If I have the creation done in a seperate form it would be hard to track where you are in the lines for that record.

To gather the step description in the main table use a recursive CF utilizing GetNthRecord( looking at the related data, but not as a lookup but an unstored calcfield.

If I store this as an calcfield then I can not have the case that when the master record changes the transcation record does not and Vis Versa.

Let me know if I am not seeing the same thing.

James

[Søren Dyhr]

Admitted do I have difficulties in seeing what you're after.

But the large number of commom fields/attributes worries me slightly, relational designs seek to zap syncronization issues once and for all. So there might be a selfjoin issue or a simple tunneling issue here.

In short the data shouldn't be stored in several location, but if you can't live with the tunneled values, must a UNSTORED calc'field change the way it's shown. The data should be stored in the portal rows only - as far as I see it. So even stuff which appears to be in the master record should actually be stored in the first related record - but perhaps displayed via the unstored calc'field.

Remember that you can decide to show only from portalrow no. 2 to no. X - This is where the duplication of records comes in, since all data except the relational primary key comes from a relation away.

Take a look at the template I have made, admitted the address is perhaps not the most obvious choice... but for illustational purposes?? Try to press the + button an change the last line slighly and by it change the legacy the next portal row is build upon ...then press + again.

--sd

demo.zip