I have just installed Version: 6.2.1.1 Build ID: 1:6.2.1~rc1-0ubuntu0.18.10.1~lo1 CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded On opening a base form for a new item, my macros use the IsNew function on the form. This used to be true for New records. It is now False in certain situations, and my macros fail. I'll have to revert to 6.1.5 to keep my systems running. I have tried to reproduce this on a simple embedded database but have failed so far. The particular case for my system using a Mariadb backend is that I open a form using: Set oOpenForm = oController.loadComponent(com.sun.star.sdb.application.DatabaseObject.FORM, sForm, false) And then it immediately triggers my 'After Change' macro which checks for 'IsNew'. This is now False, even for a form which is set to only be able to add new data. If I manage to get further information, and hopefully a reproducible case, I will post again here, but I have to revert to 6.1.5 for now and install a 6.2 test system later.
I have found a work around for this problem. It seems that the timing of events has changed. Previously there was time for the form and record to be marked as new one it had been opened before the 'after change' event was triggered. In 6.2.1.1 that wasn't true, but the IsNew status did get set later on. However, Having gone back to 6.1.5.1 and got things working with some possible workarounds, I installed 6.2.1 from Libreoffice (not ubuntu ppa), and found it was very unstable, crashing a lot. I changed from Mysql(Native) to MySql(JDBC), only to find that the mysql java jdbc connector doesn't work any more for Mariadb, so found and installed the Mariadb one. Now 6.2.1.1 worked OK (so far at least) so I upgraded again to the ubuntu pre-release, and re-installed the libreoffice-mysql-connector. However, that seems to be invisible when trying to change the database connection back to Native. To conclude, in 6.2.2.1: 1. There seem to be timing changes for form open events that mean some macros may fail (in my case the IsNew function) 2. Has Mysql(Native) been dropped for mariadb (or all mysql)? Apologies for the stream-of-consciousness and testing nature of this report. I appreciate there may end up be 0, 1 or 2 faults here.
(In reply to tim from comment #1) Can't comment on the firing of events issue, although there have been previous reports of macros not wokring because certain events do not fire in the expected sequence, so it wouldn't be totally surprising. > Mysql(Native) to MySql(JDBC), only to find that the mysql java jdbc > connector doesn't work any more for Mariadb, so found and installed the > Mariadb one. Yes, the latest mysql-java connector 8.x has at least one issue, bug 119139 (as yet unconfirmed), relating to timestamps, timezones and possibly datetime fields. It would be nice if this could be confirmed, however it does seem linked to that particular driver version (moving back to older versions solves the problem, but creates others). > > Now 6.2.1.1 worked OK (so far at least) so I upgraded again to the ubuntu > pre-release, and re-installed the libreoffice-mysql-connector. However, > that seems to be invisible when trying to change the database connection > back to Native. It should still be working with the libreoffice-mysql-connector, assuming you are using the corresponding version built for the ubuntu pre-release. I wasn't aware that one was provided in either pre-releases or snaps, so I'm somewhat surprised that you found one. If you are using the native connector from the previous distro-released version of LO, then there is absolutely no guarantee that it will work with a pre-release, in my experience. > 2. Has Mysql(Native) been dropped for mariadb (or all mysql)? No, not to my knowledge. The conenctor on most Linux distribs is now built with mariadb libraries (libmariadb) instead of mysql libraries (libmysqlclient).
Ideally, we'd need a sample db with the macro and associated instructions for use. It doesn't have to be hsqldb (although it would help). You could provide us with a DDL statement for the mysql table, and a sample ODB file containing the macro and tell us how you linked to your mysql instance (driver version and any parameters passed), so that we could adapt the ODB to our test environments.
Having been able to reproduce this on my application many times, and found a work around (basically setting default values at form load time rather by using if 'isNew' in the 'After Change' event to set defaults) I now can't reproduce the problem, even by reverting to the old macro behaviour. I don't know if this was related to jdbc or native connectors or something else If I get a native connector at some later date in the ubuntu version I'll try that. Sorry to use up your time (I hate it when stuff becomes unpredictable in this way!). If I manage to get the problem to return, I'll report again. With permission, I had better close this as 'notabug'.
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
As I said, the system on which this issue occurred has moved on to get around this issue. Further I had to back off 1.6.2 for several reasons. My attempts to reproduce this issue on a new, simple, database have not been successful thus far. I will try again once I have a 1.6.2 that works for me. It is possible that the problem was related to my using 1.6.1.5 version of the MySQL(Native) connector on 1.6.2. As I have suggested, please feel to close this report off, or ask me to do so.
[Automated Action] NeedInfo-To-Unconfirmed
ok, let's close this issue then. Feel free to put it back to UNCONFIRMED it if you reproduce the problem again.
(In reply to Xisco Faulí from comment #8) > ok, let's close this issue then. Feel free to put it back to UNCONFIRMED it > if you reproduce the problem again. OK. Thanks.