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