Apache OpenOffice (AOO) Bugzilla – Issue 113554
Base crashes after SQL insert error from a subform when using button actions to navigate through parent form records
Last modified: 2013-01-29 21:47:06 UTC
In a Base form with a subform, I have added buttons to trigger the next record / previous record functions. These aren't custom macros, just the default "action" options in the button control's properties. The subform has some required fields (i.e., with non-null constraints on the database table). If you try to navigate away from a half-completed subform, therefore, you sometimes get SQL insert errors. When using the main form's buttons to do the navigation, OpenOffice OFTEN BUT NOT ALWAYS crashes a few moments after you have clicked "OK" to the error warning. In the cases where the button method doesn't crash, the subform data is lost and the main record is still changed. I haven't figured out any differences between when it crashes and when it doesn't. It doesn't crash if you use buttons associated with the subform -- instead, the form goes straight to the "problem" field on the subform, cancelling the navigation request. This feature also happens you try to transfer focus from the subform to any non-button features of the main form. I have re-created the problem in a much simpler sample database, which I will attach in a moment.
Created attachment 70896 [details] Simple Test Database -- use the "LibraryCheckOutForm", leaving either sub-form field empty to trigger crash
@ameliab Using the database with OO.o 3.2/Ubuntu is a bit different, the office crashes every time. Using OOO330m_2 (the current development build for 3.3) after input a few records and missing data failed writes for a dozen more as test - no crash ever. Using Ubuntu 3.2 to get the crash to stop - open the database, select the menu Edit>Database>Advanced settings. On the dialog remove the tick mark from the item "Form data input checks ....". This stops the crash, the data is never written to the table for a partial record, but it is tossed away, and the main form record pointer moved to the next/prev record. Which I would agree is a design error on Bases default actions in this use case. You can work around it however, see: http://api.openoffice.org/docs/common/ref/com/sun/star/sdb/XRowSetApproveListener.html#approveRowChange But I suppose this issue as to the crash only.
@atjensen Thanks for confirming that the problem isn't exclusive to my system. And good to know that the crashing, at least, seems to be fixed in the latest development builds. I have been trying to figure out a work-around, but it's a little complicated since the macro has to be attached to an event on the mainform to trigger action on the subform -- and since I don't have any experience with the OpenOffice API. See: http://user.services.openoffice.org/en/forum/viewtopic.php?f=39&t=32890&p=150797
For what it's worth, I've discovered that simply cancelling the record change using a macro is not always enough to stop the crash. However, having the macro pause for user input, then cancelling the record change, does seem to protect against crashing. So, my guess is the crash has something to do with synchronization of multiple processes? Why else would pausing until someone says "OK" be the key to the solution? For the (rather crude) macro I'm using, see http://user.services.openoffice.org/en/forum/viewtopic.php?f=39&t=32890&p=150893#p150893
Check this still happens in OOo 3.3?
Created attachment 76306 [details] Confirming that bug still persists in 3.3 (The attachment is irrelevant -- just a text file repeating this comment. I couldn't attach it the normal way due to some quirk of the way Bugzilla imported old issues, see Bug 117094 ) Yes, the form still crashes in 3.3 on my Mac (OOO333m20, build 9567), but not consistently: it crashed the first time, worked fine for the next half dozen or so tests, then crashed again. Which basically supports my earlier guess that it is a thread synchronization issue. Sometimes those threads will return their results in the right order anyways, even without the proper checks, and sometimes they won't.