Folks,

I've been working on some scripts to search and update tables in a FM application. I've basically written Applescript functions to do this. Each has used the same type of code to create a new record when necessary:

...

create new record at database irisTitles

save database irisTitles

set lastRecord to count record of irisTitlesDB

set cell "Work No." of record lastRecord of layout 0 of irisTitlesDB to workNumber

set cell "Title" of record lastRecord of layout 0 of irisTitlesDB to workTitle as text

set cell "Title Qualifier" of record lastRecord of layout 0 of irisTitlesDB to titleQualifier as text

set cell "Title Notes" of record lastRecord of layout 0 of irisTitlesDB to "SPIRO " & titleNote as text

save database irisTitles

...

For some reason, this code doesn't work for ONE of the tables. I'm working with updating tables from a purchased FMPro application and we are importing data into the system. I've been looking at the field info, layout properties, etc. to determine what if anything is different from the other tables and can't find anything different.

I'm baffled as to why the code shown above will work for the majority of the tables I'm updating and generating the error

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

for another table. I'm running this from withing Script Editor so that I can see the events and results and nothing odd appears there.

Has anyone else had a situation where an Applescript script would not work when it did for another similar table?

Any thoughts would be appreciated since I'm basically out of ideas on this one.

Thanks,

Jack

It's possible that one of the fields you are trying to set is defined as something that won't accept text, such as a container field, or maybe a date field.

I appreciate the thought. That's one of the first things I had checked. In fact, by now I've probably triple checked the field names and data types to make sure there's nothing wrong.

I should mention that this code works if I change the record number to one that already exists in the table instead of trying to write to the newly created record, which I think is odd. Does that shed any light for anyone?