Issue 113554 - Base crashes after SQL insert error from a subform when using button actions to navigate through parent form records
Summary: Base crashes after SQL insert error from a subform when using button actions ...
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOO320m18
Hardware: Mac Mac OS X 10
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2010-07-31 02:00 UTC by ameliab
Modified: 2013-01-29 21:47 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Simple Test Database -- use the "LibraryCheckOutForm", leaving either sub-form field empty to trigger crash (19.53 KB, application/vnd.sun.xml.base)
2010-07-31 02:04 UTC, ameliab
no flags Details
Confirming that bug still persists in 3.3 (612 bytes, text/plain)
2011-04-06 22:12 UTC, ameliab
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description ameliab 2010-07-31 02:00:05 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.
Comment 1 ameliab 2010-07-31 02:04:12 UTC
Created attachment 70896 [details]
Simple Test Database -- use the "LibraryCheckOutForm", leaving either sub-form field empty to trigger crash
Comment 2 drewjensen.inbox 2010-07-31 07:10:35 UTC
@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:

But I suppose this issue as to the crash only.
Comment 3 ameliab 2010-07-31 17:38:47 UTC
@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.
Comment 4 ameliab 2010-08-01 20:40:37 UTC
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

For the (rather crude) macro I'm using, see
Comment 5 r4zoli 2011-02-11 08:13:37 UTC
Check this still happens in OOo 3.3?
Comment 6 ameliab 2011-04-06 22:12:53 UTC
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.