Script works in SE, fails when imbedded.

[gstb]

I have a simple script which takes a cell value from one db and creates a new record in another db with the same cell value. (Then relationships, portals, and other cool things happen.)

The script works great from Script Editor, over and over again.

When I copy the script into FM Pro 6 or Developer 7 it fails.

The script:

tell application "FileMaker Developer"

tell window "ProductionShedule"

tell current record

set ProdSchedSN to (get cellValue of cell "ProdSchedSN")

end tell

end tell

tell window "Materials"

tell (create new record)

copy ProdSchedSN to cell "ProdSchedSN"

end tell

end tell

end tell

V7 errors:

Write access denied

Unknown Error: -10006

V6 error:

Set Data failed. Invalid data was supplied. (Error -17005)

In V7, Following the failed FM imbedded script, the Script Editor script also fails:

tell application "FileMaker Pro"

get cellValue of cell "ProdSchedSN" of current record of window "ProductionShedule.fp5"

"1491"

create new record

record id 3.5773E+4 of database "ProductionShedule.fp5"

set cell "ProdSchedSN" of record ID 3.5773E+4 of database "ProductionShedule.fp5" to "1491"

"FileMaker Pro got an error: Set Data failed. Invalid data was supplied."

The SE script will not run until I click around on the Materials window.

ProdSchedSN is required (serial auto fill), so it should never it an empty value.

The imbedded sciript does not have "tell app FileMaker" line, or the trailing end tell.

The "tell app FileMaker" is adjusted for v6 Pro and v7 Dev.

Until the script works the cool stuff does not groove

Any assistance would be appreciated.

Thanks

Reese

[Wim Decorte]

Hi Reese,

Indirect answer that doesn't solve the AppleScript error: why not simply use just FileMaker script steps to do this? Seems strange to me that you want to hand off a request to the OS to set one field in one FM file to the content of another field in another FM file.

It could go something like this (in a script)

- set the value from the source field to a global (in its own file or in the other file)

- perform subscript in the target file that sets the target field to the value of the global.

No relationships needed for this, globals are available everywhere without relationships. You will need a TO of the table where the global lives in the target file.

If both source and target table are in the same file then it's even easier.

[gstb]

Wim,

Thanks for the reply.

>- set the value from the source field to a global (in its own file or in the other file)

I could not figure out how to set the global in the OTHER file within FM, and also could not figure out the next step; how to get the other file to copy the data to the cell of a new record.

I have more experience with Apple Scripts than with FM scripts so when I could not find a way in FM I went to AS.

I like your logic. If you could share a snippet on how to get a small piece of data from THIS record in THIS file to a new record in THAT file I would really appreciate it!

Thanks,

Reese

[Fenton]

As Wim says, you can set or get a global with a plain table occurrence of the file (table of file) from anywhere else that has a File Reference to that file's table.

Here's a simple example. In this case there is a relationship. But that doesn't matter, not to globals. (And in fact the relationship is not valid until after the 1st child record is created, given its master foreign key, and committed; but it still works.)

There is a 2nd way in FileMaker 7 which doesn't even need a global. It can use a Script Parameter. This is a variable you create on-the-fly, then get with (surprise), Get ( ScriptParameter ). It is mostly only useful with buttons however, as the button attachment dialog is where you specify the parameter. And it must be passed to subscripts (if any).

New_wGlobal.zip

[gstb]

Fenton,

Thanks for chiming in. I will have to wait to see your file as I only have FM6 here at the house.

As long as I am in one db then I follow what you and Wim have said. I can now tell you about a dozen ways to move data around within one file- it's moving it across files that has blocked my road.

Perhaps I need to better describe the situation:

One db is a schedule of production events.

Another db is a record of labor charges.

The production db lists jobs by job number, the labor db lists charges by job number.

I have a portal in the production schedule that ports the labor charges for the current record (schedule).

I am trying to create a button in the production schedule which will create a new record in the labor db with the job number of the current schedule record. Then the operator can set the fields for time and billing codes without the need to change to a different db.

Here is a two line version of the script which works in SE:

tell window "ProductionShedule" to tell current record to set ProdSchedSN to (get cellValue of cell "ProdSchedSN")

tell window "Materials" to tell (create new record) to copy ProdSchedSN to cell "ProdSchedSN"

If I change both windows to the same, ("Materials" or "ProductionShedule") then it works fine. It does not work when one window tries to tell another window what to do.

I would like to keep this in FM scripts as WIm suggested, but all the commands I see work on the current db, none address the issue: change db/window. I hope I'm missing something obvious here

Also, this project is being developed in FM Pro v6. We own Dev 7, but have completed the purchase of the 7 licenses for our users.

Reese

[Fenton]

If you have a relationship, any relationship, between 2 files you can pass a global between them. The relationship does not have to match, because globals do not belong to any particular record. In 7 you do not need a "relationship", ie., with fields involved; you just need a File Reference and a Table Occurrence. These are both present in 6, as part of a relationship; but you also need 2 fields in 6.

In 6 you can use a Constant = 1 relationship on both sides to pass the globals. If you could not pass globals between files FileMaker would be somewhat crippled, as you are thinking, in creating new records.

Here's a crazy little file(s) I created in 6 once to experiment on passing globals in 2 empty files.

ConstantTest.zip

[gstb]

OH!!

Let a relationship pass the data from Schedule to Labor, then a script can pick up that data and use it to create the new record. The approach is so different than how I write scripts that I was a bit slow on the uptake.

I was so focused on the script doing all of the work that I missed what you and Wim were saying. I write scripts in other places and am accustomed to defining the variables then working with them. Now that I get your concept I will give it a

try. Thanks for taking the time to write the files.

Now I see the call for the external script. How could I have overlooked the "Initialize button"?! At least I was not missing something really obvious

Reese

[Fenton]

Yes, you can pass data. Remember though that is a global field; available to all records, both in that table and from another table, not a regular field; available while in the record, but depends entirely on the relationship what/which is available from other tables; not available at all if no relationship, whereas a global still is.

The "Initialize" button just clears all the fields so you can try it again. The files were not meant to show how to create a new record; they were to show that you can pass a value to, or get a value from a record under many conditions, even no records at all. Which may seem of little use, but it is important if you distribute a clone (and no one can create the 1st record -).

[gstb]

I also resolved the AS question. It looks like it was a semantics issue:

tell window "ProductionShedule.fp5" to tell current record to set ProdSchedSN to (get cellValue of cell "ProdSchedSN")

tell database "Materials.fp5" to tell (create new record) to set data cell "ProdSchedSN" of last record to ProdSchedSN

I appreciate the concept of writing the script in FM so it does not need to make outside calls, and it will allow PCs work with the same db.

Reese