Apache OpenOffice (AOO) Bugzilla – Issue 108377
Forms with setting 'Add data Only = Yes' broken
Last modified: 2010-02-14 13:49:46 UTC
The Form.insertRow() method in OOo Basic raises an exception 'MySQL_Prepared_ResultSet::getInt: can't fetch because not on result set' using MYSQL(Native) connector. When using MSQL(JDBC) the exception is 'Illegal operation on empty result set'. The same code works OK in version 3.1.1, it just started when I installed 3.2 RC1 then RC2. It is also raised when using the 'save record' action in a form button.
If I use 'On Error Resume Next' in the code the routine returns and the row is inserted OK. However this is not possible with the save record action in a button. It is also not good practise.
@chrisbrand Would it be possible for you to attach a text file with the basic code where this happens, and enough info so that I could try to reproduce here. Thanks
Created attachment 67241 [details] Basic code and description of error
@chrisbrand Using XP (SP3), OOO320_RC2 and MySQL Connector 1.0.0 I have not been able to reproduce the problem. Tried some simple test cases and an existing form with some basic for inserts/update. Are you using the most recent MySQL connector on both machines? Would you, on the 3.2 machine, add this line: print ThisForm.isNew() just before the line ThisForm.InsertRow() It should put up a message box with TRUE, but let me know if you could.
I am using XPPro (SP3), OOO320_RC2 and MySQL Connector 1.0.0 Print ThisForm.isNew() gives the message box with TRUE then ThisForm.insertRow() produces the exception. As I said, it still inserts the record into the database OK but stops program execution. I uninstalled OOO320_RC2 and installed OOO311 and the same form operates perfectly with no exceptions. I did find one form, the stock control form, does save the parts data record successfully with no exception generated. I have no idea what the difference is with these two forms as I have scanned the properties settings and they all appear the same. Every table has one primary key which is of type Integer[INT] and auto incrementing.
@ chrisbrand well drat - of course it has to works sometimes for you... OK - well the door for 3.2 is shutting pretty quickly, given you have a work around and that so far I can't reproduce the bug I hope you would agree that it appears not to be a showstopper for 3.2? So - I will work with you to try and narrow this down for sure, but it will be a few days before I can really do so - mind if I contact you direct via email about this, then?
I wouldn't dream of standing in the way of the full release of 3.2. Please, just concentrate on getting the full release out there. Feel free to contact me by email as this is the fastest, I would dearly like to sort this out. It's probably a bit of slack coding on my part and 3.2 is a little less forgiving that 3.1.1. I'd like to know just where it is a little less forgiving.
Updated summary Checked with OOO320_RC5, XP To reproduce: Download the attached database Open form Task Enter data in all control Try to save the data ============================== On that post of the data - the data is written correctly to the table - the dataform displays an error dialog to the user saying that the data was not written - the data entered in the forms controls is still displayed - the form navigation controls all show that the form needs to be saved -- there is a clue here as the navigator shows 2 records which should never happen with this type of form. - if the user believes what the application just told them and tries to post the data again -- a different, more onerous, error dialog is displayed ( cause now there really is an error state in the dataform control ) At this point if the user hits the REFRESH button on the navigator, or tries to close the form - A warning dialog informing them that there is unsaved data -- there only choice is to tell the application to throw away the new data --- of course the data is in that table...they just don't know it ==============================
Created attachment 67615 [details] test form TASK
Assign to developer Set initial target
the issue is not limited to MySQl connector
confirming already broken with OOO320m6 (tested on Ubuntu Linux) @Mechtilde: wanna have a look?
duplicate of issue 108390, isn't it?
yes - (explains why felt like de-jevu arrgh) close this one and re-open the other, then?
yes and no :) The other one is fixed, but only in a CWS so far, which is not yet integrated => no need to re-open. Thanks for the feedback, and more important for the work you put on this. *** This issue has been marked as a duplicate of 108390 ***
Couldn't a macro get between the post and the first error dialog and suppress it? Then handle a fixup of the daraform so the user can just keep working..If so we could attach the workaround macro to the original posting at the user forum. I'll give that a go this evening..
cc'ed myself and courious to see, whether this is somehow related to what I observed and reported under issue No.108299 : the displayed data vary from the stored data due to (I guessed so!) a version change in handle the default field-format. Martin
Attached is a .bas file with a couple of routines to use as work arounds for this. To use this - open your Base file, add if you need to, a basic library to the file, copy the contents of the attachment into an empty module in the library. The comments in the file should give you the information to make use of it. For questions please use the mailing list users @ dba.openoffice.org or drop me a direct email.
Created attachment 67762 [details] basic macro
This is what I did to fix the problem without too much complication. I changed the Add data only of all my forms that had 'yes' in them to 'no'. Then, at the start of my ResizeOnOpen subroutine, which I have for every form that is loaded, I added: Sub ResizeOnOpen(Event As Object) Dim ThisForm As Object ThisForm = Event.Source ThisForm.MoveToInsertRow() The rest of my initialsation routine...... End Sub And whallah! It all works fine. Both the InsertRow() method and the 'Save record' action of the forms save the new row correctly without error.
great
close the duplicate