No error thrown on GTRR
FMPA9 and FMPA11
Operating system version
Windows XP Professional SP2
Description of the issue
There are times we use a GTRR and then want to delete the found related records. However, if something has happened that the child is no longer valid (foreign key changed to unstored, indexing turned off or index for the child table has trashed), script does NOT produce an error code.
Steps to reproduce the problem
File with two tables (Parent and Child). Set the child key to unstored or set index to none (without automatic index). This would be the situation also if the index in the child table corrupts.
Script with error capture on then GTRR to child table. Once there and if no error, delete all records, something like:
Set Error Capture [ on ]
GTRR to child table
If [ Get ( LastError ) ]
Go to Layout [ original layout ]
Delete all Records
There should be a error generated. Instead it produces a message of “This operation could not be performed because one or more of the relationships between these tables are invalid.”
Error should be generated so script can be controlled.
There is only an OK button. User clicks okay and the SCRIPT CONTINUES and deletes the records in the parent table instead.
Exact text of any error message(s) that appear
“This operation could not be performed because one or more of the relationships between these tables are invalid.”
This uncontrolled message will also cause a server hang or robot hang because nobody is there to press OK. FMS11 allows time out on scheduled scripts if they run too long but that is not the issue.
All I can come up with is to check for related records as well, something like:
If [ not IsEmpty ( child::primarykey ) ]
… continue script
… stop script
This may already have been reported. I have given up on trying to keep track of all the unfixed bugs. This is very serious because we had an index fail in the child table and it deleted all of the parent records even though I had generic error trap on to protect from ANY failure.
The other option may be to check that the script moved to the other layout but that means hard-coding the layout in the script and that should not be necessary.
AN ERROR SHOULD BE THROWN ... at least one of these:
101 record is missing
103 relationship is missing
107 Index is missing
110 related tables are missing
401 no records match the request
407 one or both match fields are missing (invalid relationship)
415 one ore more of the required related records are not available
510 related value is empty or unavailable