Rewrite this script to be a find between DBs instead of layouts?

[Karen1958]

Here's the script:

> Go to Layout ["Perm Master Records"]

> Enter Find Mode []

> Go to Field ["PR~ArtistTitle"]

(this part is actually a separate script from another layout, so in the new layout it pauses in find mode waiting for user to enter a word or phrase, then, after a particular record is selected from the find returns, this script is run:)

> Set Field ["check box Master", "Y"]

> Copy [select, "PR~ASIN"]

> Go to Layout ["Main Records"]

> New Record/Request

> Paste [select, "ASIN"]

> Set Field ["check box Main", "Y"]

> Go to Layout ["Perm Master Records"]

> Enter Find Mode []

> Set Field ["check box Master", "Y"]

> Perform Find []

> Copy [select, "PR~ArtistTitle"]

> Clear [select, "check box Master"]

> Go to Layout ["Main Records"]

> Enter Find Mode []

> Set Field ["check box Main", "Y"]

> Perform Find []

> Paste [select, "ArtistTitle"]

> Set Field ["OK for int'l ship", "2"]

> Set Field ["Check Daily", "No"]

> Set Field ["Listing Status", "Wait"]

> Clear [select, "check box Main"]

Clunky but it works.

Now, however, I want to separate the "Master" layout from the rest of the layouts in the DB, and create a separate DB from it. I've tried to perform the same find/paste/etc. commands but a relationship must then be created between the fields in question, and I can't seem to make this work afterwards no matter what I try.

Help!

[-Queue-]

Instead of copying and pasting, set the desired values to global fields using Set Field. Create a relationship based on a calculation of 1 in both files and use Set Field, referencing the globals, to set the values in the new file.

It appears as if you were using the original file as a pseudo-multi-file (treating each layout as a table, instead of creating one file to hold each entity and relate them appropriately). If so, this process may be somewhat more complicated. However, I would still make the same suggestion regarding ditching Copy/Paste.

[Karen1958]

The last part is exactly correct: I'm curently trying to treat that second (4th, actually) layout as a separate table, and now it's getting messy.

I'm not sure I understand your answer, though? None of the fields I'm (currently) copying and pasting should be *global* fields...were you referring to something else when you referred to "desired values"?

And, in any event, getting rid of the copying & pasting routine is not my primary concern right now. How do I create a new DB (table) from what is now a layout and still be able to lookup and copy values from one to the other without the records being linked as in a relational DB?

[Kent Searight]

Can you attach an example of what you currently have and an explanation of what you'd like to achieve? From the sound of this post and the other post you have going on, I agree with nylon, "It sounds like there's a fundamental design flaw in your dB but from your description, it's hard to determine where it is."

[bruceR]

The last part is exactly correct: I'm curently trying to treat that second (4th, actually) layout as a separate table, and now it's getting messy.

I'm not sure I understand your answer, though? None of the fields I'm (currently) copying and pasting should be *global* fields...were you referring to something else when you referred to "desired values"?

And, in any event, getting rid of the copying & pasting routine is not my primary concern right now. How do I create a new DB (table) from what is now a layout and still be able to lookup and copy values from one to the other without the records being linked as in a relational DB?

1. You don't create a table from a layout. That's exactly backwards.

2. You *DO* need to use globals to pass parameters to scripted find actions. You first set the value to be found into a global. Then you enter find mode and set the target field to the contents of the global.