Issue 108377 - Forms with setting 'Add data Only = Yes' broken
Summary: Forms with setting 'Add data Only = Yes' broken
Status: CLOSED DUPLICATE of issue 108390
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOO320m6
Hardware: PC All
: P2 Trivial (vote)
Target Milestone: OOo 3.2.1
Assignee: Frank Schönheit
QA Contact: issues@dba
Keywords: regression, release_blocker
Depends on:
Reported: 2010-01-16 10:45 UTC by chrisbrand
Modified: 2010-02-14 13:49 UTC (History)
7 users (show)

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

Basic code and description of error (120.61 KB, application/vnd.oasis.opendocument.text)
2010-01-17 11:19 UTC, chrisbrand
no flags Details
test form TASK (18.85 KB, application/vnd.sun.xml.base)
2010-02-04 16:37 UTC, drewjensen.inbox
no flags Details
basic macro (14.57 KB, text/plain)
2010-02-11 18:52 UTC, drewjensen.inbox
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description chrisbrand 2010-01-16 10:45:19 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.
Comment 1 chrisbrand 2010-01-16 10:56:30 UTC
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.
Comment 2 drewjensen.inbox 2010-01-17 00:35:55 UTC
@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.
Comment 3 chrisbrand 2010-01-17 11:19:28 UTC
Created attachment 67241 [details]
Basic code and description of error
Comment 4 drewjensen.inbox 2010-01-17 16:24:15 UTC
@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.
Comment 5 chrisbrand 2010-01-18 11:25:13 UTC
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.
Comment 6 drewjensen.inbox 2010-01-18 12:32:24 UTC
@ 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?

Comment 7 chrisbrand 2010-01-18 20:55:06 UTC
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.
Comment 8 drewjensen.inbox 2010-02-04 16:36:41 UTC
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
- 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
Comment 9 drewjensen.inbox 2010-02-04 16:37:30 UTC
Created attachment 67615 [details]
test form TASK
Comment 10 drewjensen.inbox 2010-02-04 16:38:57 UTC
Assign to developer
Set initial target
Comment 11 drewjensen.inbox 2010-02-04 16:43:56 UTC
the issue is not limited to MySQl connector
Comment 12 Stefan Weigel 2010-02-04 17:08:49 UTC

already broken with OOO320m6 (tested on Ubuntu Linux)

@Mechtilde: wanna have a look?
Comment 13 Frank Schönheit 2010-02-04 21:11:07 UTC
duplicate of issue 108390, isn't it?
Comment 14 drewjensen.inbox 2010-02-04 21:38:58 UTC
yes - (explains why felt like de-jevu arrgh) close this one and re-open the
other, then?
Comment 15 Frank Schönheit 2010-02-04 21:47:00 UTC
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 ***
Comment 16 drewjensen.inbox 2010-02-04 21:51:05 UTC
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..
Comment 17 mhatheoo 2010-02-05 01:02:54 UTC
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.

Comment 18 drewjensen.inbox 2010-02-11 18:44:57 UTC
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 @ or drop me
a direct email.
Comment 19 drewjensen.inbox 2010-02-11 18:52:15 UTC
Created attachment 67762 [details]
basic macro
Comment 20 chrisbrand 2010-02-12 22:22:46 UTC
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

    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.
Comment 21 drewjensen.inbox 2010-02-12 22:23:59 UTC
Comment 22 Mechtilde 2010-02-14 13:49:46 UTC
close the duplicate