I'm writing a script that is triggered (onobjectvalidation) from a tabbed portal on a layout. Part of the script performs a search on different layout and returns with some variables set from that search. My problem is that when I return to the original layout, I can't seem to consistently get back to the point of origin (field from which the script was triggered). There are some instances in which the user will be triggering the script from the 4th row of a 10 row portal. The standard options of 'First, Next, Previous, Last' in the 'Go to portal row' command don't offer the 'go to' functionality that I need. I somehow need Filemaker to remember which row I was on when the script was triggered and to go back to that spot after returning from the search (on a different layout).

I've been wrestling with for days. Any help would be appreciated.

you could store the portal row number in a variable go do the script then issue a go to a related field in the portal and then go to portal with the portal number stored in the variable - i find this better then going to layout object (by name)

Another option is to not to disturb the current window, sort order, selected tab, or scrolled portal - instead spawn a new window OFF SCREEN perform your action set your variables then destroy the offscreen window - you will land were you left. ---

The only caveat is that you may need to commit the current record or at least close the current record as if you are "editing" the current related portal and your new window tries to edit the same record you may get an error. If its the case of commit you may still need to store the portal row number to a variable and return to the portal.

The only caveat is that you may need to commit the current record

Part of the script performs a search on different layout

I don't think you can do that without committing the records (parent and portal) first - which kind of defeats the purpose of running a script OnObjectValidation.

i guess an alternative - would be perhaps a SQL plugin - that can use field level validation it could query another table for ID's and test for a boolean and then pass or fail the test. No need for script to trigger. If it fails since the record isn't committed a revert can undo the entry in the parent/child.

I don't know. I suppose it depends on what is being validated (assuming validation is the purpose here).

Thanks for the responses. You've hit on the 2nd problem I'm having: I need the record to not commit before the script completes its search as that's the whole point of the script. The script is supposed to do a search for a purchase order from the same client with the same value as what was typed in the field that triggered the script. If the PO number exists, the record is populated with the information from the existing PO. If the PO doesn't exist, a new PO is created. However, when the script returns from the search and gets to the original portal row, the record has already committed and a new PO has been created regardless of whether it already exists. It was my understanding that onobjectvalidate performs the script BEFORE internal validation and saving of the record. This is driving me crazy. It seems like a simple, common thing for a database to perform.

Enter the client name into a global field. Use the value for the search.

It was my understanding that onobjectvalidate performs the script BEFORE internal validation and saving of the record.

That is correct, but it is not the source of the problem. The real issue here is that you cannot leave an uncommitted record, so when your script enters Find mode, it also commits the open records. One possible solution is to open a new window for the find, then close it to return to the uncommitted record in the original window.

The script is supposed to do a search for a purchase order from the same client with the same value as what was typed in the field that triggered the script. If the PO number exists, the record is populated with the information from the existing PO. If the PO doesn't exist, a new PO is created

Off topic: I didn't get this completely, but there is something that doesn't feel right about it.

You could try using a relationship to "find" the record you need, based on a match with the input field.