Let's try to first simplify it a bit: you don't need the Go To Object or the Commit script steps.
If you want to use Set Field by Name then make sure that the name is correct and trap for an error right after that step instead of waiting to trap for error after the Perform Find...
Out of context, yes the go to object step is unnecessary. This is part of a modular script, and in this case it is going to a field designated as the primary key on the layout. The set field by name step calculates the fully qualified field name and sets the search criteria to it. I added the commit record/request step to see if that made any difference, but the same behavior is observed with or without that step in place.
Sent from my iPhone
Sorry, I was in a hurry. Here is a better look:
Enter Find Mode
Go To Object [$pk_object] // designated earlier, primary key field for the layout in question.
Set Field By Name [Get (ActiveLayoutTableName) & "::" & Get(ActiveFieldName) ; $id ) //simple numeric id value.
Perform Find [ ]
error shows up on server log, pause on error in script debugger, but stepping through the script executes as expected (no error).
For clarity, I did test this in a single record table. So I know it is executing in a case where there is data to find.
Also, this is the first instance of a perform find operation up to this point.
Can you run this file ... locally (no FMS) with no problems? That would be my first test.
I looked this error up on the web and there are lots of articles about it -- everything from potential registry issues or even malware and such.
From my perspective, if you can step through the code and get the record with no errors, but running the code on the server gives an error, then perhaps FM itself should get involved.
What I would also try in a situation like would be to use another instance of FMS and try to take my own copy of FMS out of the loop so to speak. Depending on what happens (error, no error), you would be in a better position to figure out what's going on or at least eliminate some pieces (divide the problem space).
These kinds of problems are annoying for sure.
Post back with results.
Running the file locally produced the same odd error. I ran a bunch of other tests, isolating everything down to just the steps in question and continued to get the same error. I reproduced the actions in a new copy and did not get the error. So I finally ran a file recovery as a last resort, and that fixed the issue. I suppose I need to move that action a bit higher on my list of troubleshooting steps. Thanks for the assistance.