My problem sounds easy:

I want to copy data from one to another file without a keyfield or any
other link.
I thought a script "Copy" like this would do it:

Open file ("a")
goto field (a::atext)
copy (a::atext)
goto field (b::btext)
paste(select;b::btext)

This script is located in file "b"

In file "a" is a perform script "Copy"

Perform script ("Copy" from file:"b")

The script does not copy the contents of field atext into btext. It
copies data which were accidentally in the memory from a former
copy/paste action.

What is wrong with the script? I use FM8.
What could be a easy solution ?

Hermann

Import?

Matt

Hermann Siemandel wrote:



--

In article <1h7bw8s.1xaneimc4u0lcN%h.siemandel (AT) nefkom (DOT) net>,
h.siemandel (AT) nefkom (DOT) net (Hermann Siemandel) wrote:

The main problem is that your Copy command needs to select the field
content first - just like you would manually select text before copying
it.

You also don't even need the Go To Field commands at all since the Copy
and Paste commands will do that anyway.

This means your script command should be:

Open ["a"]
Copy [Select; a::atext]
Paste [Select; b::btext]

(Im' not sure why the Open command is there, it may not be needed
either.)



A second possible problem is that for the Copy and Paste script
commands to work, the fields both need to be on the current layout.

Instead of Copy / Paste you could simply use the Set Field command,
meaning your script becomes even simpler.
eg.

Open ["a"]
Set Field [b::btext, a::atext]

This has the bonus of not needing to have the fields on the current
layout and the fields will not become selected so the process is
invisible to the user. It also doesn't require running a script in file
/ table "b" (as long as the "a::" and "b::" mean you've actually got a
relationship link between "a" and "b").



It could also depends on what you're trying to do, but there may be a
better way to transfer the data.

You could go to the target file / table and use the Import command to
copy the data from the original file / table, but the original file /
table would need to have only the records you want to copy in it's
Found Set. This method also creates new records in the target field /
table rather than changing existing records.

Another way is to temporarily store the data in Global fields and then
got to file "b" and create the new record and use Set Field to copy the
data over from the Global Fields.


Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

Helpful Harry <helpful_harry (AT) nom (DOT) de.plume.com> wrote:


Even in the same layout it didn`t work.


This is probably the way to do it. But i must first make a find script
for selecting the one specific record i want to transfer.
But it works fine.

Here is a similar example. Set a global variable ($$model_cd) to the
value of the MODEL_ID field in the first table (scoring). See if that
value exists in the second table (dummy_pics). If not, create a new
record and set its MODEL_ID field to the value from the first table.

Michael Paine
-----------
Set Variable [ $$MODEL_CD; Value:scoring::MODEL_ID ]
Enter Browse Mode
Go to Layout [ “DUMMY_PICS” (DUMMY_PICS) ]
Enter Find Mode [ ]
Set Field [ DUMMY_PICS::MODEL_ID; $$model_cd ]
Perform Find [ ]
If [ Get(FoundCount)=0 ]
New Record/Request
Show All Records
Set Field [ DUMMY_PICS::MODEL_ID; $$model_CD ]
Perform Script [ “DRAW_DUMMY” ]
End If


Hermann Siemandel wrote:

In article <1h7cwfl.1qatwmg1vis1icN%h.siemandel (AT) nefkom (DOT) net>,
h.siemandel (AT) nefkom (DOT) net (Hermann Siemandel) wrote:


Then make a link. One way I use to transfer data between files without
obvious matching key fields is via the constant relationship (FM 6
technique, perhaps 7 or 8 does this kind of thing completely
differently). In file a and b create calculation fields where the calc is
simply the number one, call the fields "constant." These utility fields
will always contain a one across all records in both files.

Create relationships based on the constant fields as if they were key
fields between a and b. In your specific example above, you would only
need a relationship from b to a. Call the relationship a_constant.

In a create a global field for the transfer, call it g_transfer.

Now you are in a record in a, looking at the atext field, wishing it could
be placed in the btext field over on b. Assuming you have isolated your
target record in b correctly, your script (running in a) is:

Set Field (g_transfer, atext)
Perform Script (External)

The external script in b is:

Set Field (btext, a_constant::g_transfer)

I find the constant relationship invaluable for many applications. I work
in a srved environment and have several one-record utility files,
"preference" files and data entry files where the user enters into global
fields only, and the contents of the globals are installed in "real"
fields when a "commit" button is clicked.

Steve Brown

In article <1h7bw8s.1xaneimc4u0lcN%h.siemandel (AT) nefkom (DOT) net>,
h.siemandel (AT) nefkom (DOT) net (Hermann Siemandel) wrote:

Use File >> Import Records >> from file

This is very powerful and flexible, can be scripted for repetitive use,
can be set to either add records or update records based on a match
field you specify, etc. It can work among data tables within one file,
or between files. You can import all or a few fields.

It has nothing to do with relationships. Everything is handled within
the Import process.

Bill Collins

--
For email, remove invalid.

Bill <bbcollins (AT) invalid (DOT) earthlink.net> wrote:

problem with a easy small script using "import without dialog"

Thx

Hermann