Ok so I figured it out - obviously needs to include the freaking table as well:
Set Field By Name ["transactions::g" & $user & "_done"
Warning: If you should ever go to Manage | Database | Relationships, find the "Transactions" table occurrence and alter its name, your script step will fail. Renaming this field in transactions could also make the step fail.
This may be an unavoidable issue, but sometimes a way can be found to set up the first parameter so that literal text is not used to produce the TableOccurence::FieldName text.
Also, the names here suggest that you are using separate fields where you might be better off setting up a table with different records for each user. For one thing, adding an extra user then becomes a process of adding a new record instead of adding a new field.
Thanks Phil, but my last post was somewhat premature, this isn't doing what I expected:
Set Field By Name ["Transactions::g" & $user & "_done" ; "true"]
It's not doing anything, even in script debugger the data viewer doesn't show that field...
But yes I see your point about user records, thanks
If no field is being modified, the most common explanation is that some part of the text expression in the first parameter isn't exactly correct and thus does not evaluate to produce the exact table occurrence::Field Name reference needed to access that field and set it to the value of the second parameter.
A second possibility is that the Transactions table occurrence might not be accessible from the current Table Occurrence context at the time the script executes.
Ok, finally really sorted it - I was trying to use a local variable to construct a fieldname for a global field