We have a situation where we do a JDBC INSERT into a FileMaker table. This works fine.
However we follow up that INSERT with an ODATA call to run a Script and passing a parameter.
Here's the problem: If the script doesn't create a new record and relies on the record INSERTed, the parameter we send to the Script via ODATA is not written to the field referenced in the script.
But...if we create a record first in the script, and pass the parameter with ODATA THEN the parameter is written to the FileMaker field.
But, in this second case we now have two records.
Since we need the ODATA parameter written to the same record as created by the INESRT statement, it seems that FileMaker is having an issue with the "record context" or something like that when ODATA call happens after the INSERT
The script seems to be on the wrong record or something after the INSERT and the ODATA call.
What should we do in the script so the script can find the right record just created by the INSERT so it can write the script param sent by ODATA?
Thanks much in advance,
I would be looking at the internal record ID. For integrating with external systems I created a calculated field, Get(RecordID), which can be used for searches.
3 Likes
Thanks Malcolm.
Would you please give me more details on this approach? Sounds promising.
Currently, there is a Java program that is doing huge INSERTs in one table. Once those are done, the code creates a record in a “jobs” table in FileMaker. Then, the code calls the FileMaker script passing the JSON Parameter which we want to be able to parse and write some fields from into the Jobs table. No problem parsing with FileMaker, but due to the context issue, the script doesn’t “see” the parameter to begin with.
As you read above, FileMaker doesn’t have the context to receive the parameter when the ODATA calls the script, so it’s not saved.
Look forward to hearing back.
Thanks again,
The above is likely correct. A script invoked via PSOS, ODATA, or DAPI will start in its own new session, which makes it especially likely that its starting context may not be at all what is needed for the task at hand. Reliably handling this requires having code in place that takes responsibility for establishing any needed Table Occurrence and Record context.
What should we do in the script so the script can find the right record just created by the INSERT
Doing this is typically just a matter of writing a few additional lines of scripting to navigate to an appropriate layout, and then perform a find to ensure that the proper record has been found.
@Malcolm gave you a good tip for how to implement such a scripted Find. If your call to the script includes a Record ID value as part of its parameter input, then the script can use that value to isolate the appropriate record by performing a find against a field such as Malcolm mentioned.
Regardless of how you implement it, I recommend including error trapping/handling, so as to avoid snafus if the record can't be found, or is locked, or otherwise not as expected.
FileMaker doesn’t have the context to receive the parameter
Context is unlikely to be at play with respect to the script receiving a parameter. If the parameter has been properly supplied with the ODATA call, then I would be surprised if the script parameter is not being received by the script.
That said, honing in on establishing the context does seem apt. It's just that the point of breakdown is not likely to be where the script receives its input parameter; rather the breakdown probably occurs at the point where the script attempts to write to a target record which has not been established as the current record. @OliverBarrett I believe you already suspected this, but I choose to spell it out clearly for the sake of anyone who happens to read this post.
3 Likes
At the point of record creation the record will have an internal record ID which you can get with Get(RecordID). You need to grab this ID and pass it back. The API all returned the record id when new records were created, so you got that done for free. You'll need to ask your Java program to do this for you.
Having a calculation field in the table, such as "fmRecordID" which is simply Get(RecordID), allows you to find it easily. Before we got the new ability to generate a found set with a list of record IDs the calculated field was the easiest way to locate the record within FileMaker.
Whichever way you choose to do it, you use the record id to locate the appropriate jobs record.
2 Likes
Thanks Malcolm. I got it all working. 
2 Likes
Steve, thanks as always. I sincerely appreciate your insights and always benefit from reading your posts.
Good news: I got it all working!
Thank you again.
1 Like