Set field in another file to a specific record

[merkaba22]

I have a found set that I can export to another file using this script:

Set Field ["PO info::Manufacturer," "MfgrCompany"]

Go to Record/request/Page [First]

Loop

Go to Record/request/Page [Exit after last, Next]

Set Field ["PO info::Sort 1, "Buy Select"]

Go to Record/request/Page [Exit after last, Next]

Set Field ["PO info::Sort 2, "Buy Select"]

etc.

End Loop

Which triggers the lookups needed in the file with "manufacturer" and "Sort 1".

This script only seems to work on the first record of that file (the file "Set Field" is directed to) -- is there a way to direct it to the last, next or any record in that file?

[-Queue-]

PO info::field1 refers to field1 in the first related record in PO info. If there is only one related record for all records in the table in which you're looping, then naturally, it will only set that record's fields and continue to change them as you loop through the current table.

You need a unique relationship between the tables for each record. This is usually done by linking a parent key field to a child key field. You would create a loop to set the current parent record's key in a global, go to a layout associated with the child TO, create a new record, and set a foreign key field in that record with the global. Now there is a unique one-to-one relationship for each parent and child, so you can set child fields from the parent record and be assured that they are being set in the correct record.

Another option, with the advent of v3, is to directly import your found set into the secondary file.

[merkaba22]

I need to take the data in a found set of records (up to 40 of them) with 50 entries each to one record in another file.

I do this by copying the field that holds the first common denominator for the found set in a script that triggers a script in the target record of the second file to paste that value/name into a field and then returns back to the found set file to trigger a script to set fields like I posted -- this triggers a lookup in the target record and works beautifully -- I have 40 relationships between the two files and all the data comes through and is organized in up to 40 sets (a set for each record of the found set).

Since the found set is temporary I am not sure I understand how to make a unique relationship between the two files -- I have no experieince with globals yet. Or does your solution work all the same and I am a bit slow?

[-Queue-]

I'm unclear on the idea of up to 40 records in a found set with 50 entries each, or do you mean 50 fields that need to be transferred?

You also refer to 40 sets. Is that in the original or new file? It sounds like you end up with 40 sets in the new file, which doesn't make sense if you are talking about combining the 40 old records into one new record.

[merkaba22]

In one file there are 280 records -- one for each ring style offered by various manufacturers.

The found set is defined by manufacturer which can comprise up to 40 records. Each record tracks up to 50 different selectable values (via pop-up lists, etc.) for the varieties and numbers of ring sizes and stones that are associated to each ring style.

Accordingly, any found set will have up to 2000 (40 x 50) distinct values that need to be transferred -- and these via scripts with "set fields", 40 relationships and lookups, etc. are transfered from the temporary found set to one permanent record in another file and that file has 40 distinct sets of 50 distinct fields to receive that info. And that much works as intended.

Yes, there are 40 sets in the new record whereas there are up to 40 records in the found set in the old file.

I hope that is more clear becasue I just need to find a mod for my script that will allow a new found set to be transfered to an new record in the new file.

[-Queue-]

By set, I'm assuming you mean group of fields or repetitions. Either way, it sounds like it would be much easier to break these 'sets' into related records that you can view/modify in a portal. Then again, you basically have this setup in the original file, so I'm not seeing the benefit of moving them to another file. The only real benefit would be that you wouldn't need client info in each related record, only the unique client id.

What exactly is the purpose of moving this wealth of data to a single record in a new file?

[merkaba22]

I sit here nervously laughing because I don't want to make this harder than it needs.

Basically, I modified the first file (with the 280 records) with a new layout in a list view with added fields so that provisional numbers of rings in sizes and settings could be set.

This allows the user to create a found set (by manufacturer) and expirement with order details -- once decided, this wealth of data needs to be formalized into a PO that would be sent via email and then kept in a permanent way -- if the found set were broken down into related records, I would still need to comprise all of them for a PO. A PO could be set up against deliveries that once accounted for would feed an inventory accounting that could be viewed in full detail at any one time.

[-Queue-]

If each record has a field for the PO id, it should be easy to link them and view the PO line items in a portal. You can also validate the fields so that once a PO has been set, changing a field triggers a warning message that the PO has been set and cannot be modified, instructing the user to click the 'Revert' button to undo the change.

Alternately, you could import the records into another file and only display them via portal, with all fields formatted to not allow entry, so that no data can be changed.

The overhead in either situation would be much less than it would be to keep all data in one record and would allow for much simpler scripting when setting a PO.

[merkaba22]

Just a quick note of appreciation to "Queue" and all those who endeavour to help up beginners get up to speed -- this is a fantastic forum -- I am very grateful for everything here!

Thank you.

[Søren Dyhr]

Hi Geoffrey

I've just been reading your old posts, and in this thread would you benefit from grasping the idea of this template although still in version 3(4) ...as a way to organize your data:

http://www.dwdataconcepts.com/dl/tm/Compile_INV2.sit

--sd

[Søren Dyhr]

Hi Geoffrey

I've just been reading your old posts, and in this thread would you benefit from grasping the idea of this template although still in version 3(4) ...as a way to organize your data:

http://www.dwdataconcepts.com/dl/tm/Compile_INV2.sit

--sd

[Søren Dyhr]

Hi Geoffrey

I've just been reading your old posts, and in this thread would you benefit from grasping the idea of this template although still in version 3(4) ...as a way to organize your data:

http://www.dwdataconcepts.com/dl/tm/Compile_INV2.sit

--sd