Not sure what's happening here, but I'd be looking at if the layout of the "super parent" set to save record changes automatically - it could be what is happening?
thank you very much for your reply.
Yes it is, but that is no problem if some other error occurs.
Example: If I lock a record in another window, the superparent reverts properly without saving anything.
If I turn this option off I get a dialog box asking if I want to save the changes. As far as I can see there is no way of avoiding that box (the script already uses ErrorCapture) and I certainly don't want the user to see it...
if error capture is on, perhaps a get(lasterror) and revert record might get you out of the ugly Save changes dialogue.
It still seems odd that an error should commit the record though, but without knowing the script, I can't really tell you what the issue is.
I read a few minutes ago on a German forum that you can not avoid this box if you turn this option off.
Nevertheless I found a way to have this option turned on an temporarily suppress the commit in Todd's video on commit record www.geistinteractive.com/2011/08/09/understanding-commit-record-video/ (starts at 22:36)
I will test if the error described above occurs in a smaller test file and then post it here together with this workaround.
This problem occurs in a testfile as well, so it seems that error 102 really commits the record.
My testfile has two buttons ("unwanted commit" and "suppressed commit") leading to this error.
"Unwanted commit" should revert, but does not because the record has already been committed. This can be seen, because the first edit is stored.
"Suppressed Commit" reverts as expected by using another layout with a script triggering on commit. I have built this second script with a short pause to show that the first field is really edited and then reverted.
The variable $PDF that is inserted into the container is not declared since I do not really want to save anything here, but just show the error.
Is there something I am doing wrong or can we safely say that this error commits the record?
Error 102.fmp12.zip 70.2 K
You are right. This is a bug. But it isn't the Error 102 that is causing it. Error 102 happens for lots of reasons and it normally does not commit the record. But "Insert File" into a related field as the target that is not on the layout definitely doesn't work as it should. It should not commit the record. The Error number isn't the relevant thing
You should report it. and submit the test file.
Make the Test File really simple. Break it down to the fewest number of steps that you need to demonstrate the bug
Thank you very much for your reply. I will report this bug as you suggest.
Meanwhile I will add a few lines to the scripts of your transaction module to suppress all commits on the transactions layout except for those commits in the module. Just in case I forget to put container fields into the layout...