Description: using a base hsqldb file as a data source causes a pop-up message "Confirm Migration". This may be ok, if a user open a base file first time, but unfortunartly this massage appears every time, when you call a connection via macro. macro stops at this moment and it is never a good idea, when users will migrate at this time! Remove this message imitatively! Steps to Reproduce: 1. register a base file with hsqldb as darta-source 2. write a macro, with uses data out of the database. therefor connect to database Function knp_getConnection_BaseDok Dim oDBC As Variant Dim oDataSource As Variant On Error Goto Fehler: oDBC = createUnoService("com.sun.star.sdb.DatabaseContext") oDataSource = oDBC.getByName("NameofDataSource") knp_getConnection_BaseDok = oDataSource.getConnection("","") Fehler: End Function 3. run macro - Actual Results: popup message appears at every connection call and every data-transfer Expected Results: no popup at all!! Reproducible: Always User Profile Reset: No Additional Info:
I guess this is covered by bug 117120. Closing as a duplicate *** This bug has been marked as a duplicate of bug 117120 ***
*** This bug has been marked as a duplicate of bug 121599 ***
Let's keep it a new and block bug 121599
Hi, So the expected result is no popup dialog. There are still two alternatives: - The migration assistant runs silently for all the HSQL databases it touches. - No migration Which one would be better?
(In reply to Tamas Bunth from comment #4) > There are still two alternatives: > > - The migration assistant runs silently for all the HSQL databases it > touches. > > - No migration > > Which one would be better? IMO, no migration. Someone who programs access to an hsqldb embedded ODB via macro programming could be said to be supposed to know that the move to Firebird as default is underway - thus, if the db hasn't yet been migrated, the macro developer has deliberately planned it that way, and decided to stick with hsqldb (at least until such time as they decide to migrate to Firebird out of choice and adapt the macro to deal with that). At worst, what happens if no migration occurs ? The user continues to be able to use the database as before, and the macro continues to work as planned by the original developer of the macro program.
(In reply to Alex Thurgood from comment #5) > (In reply to Tamas Bunth from comment #4) > > > > There are still two alternatives: > > > > - The migration assistant runs silently for all the HSQL databases it > > touches. > > > > - No migration > > > > Which one would be better? > > > IMO, no migration. Someone who programs access to an hsqldb embedded ODB via > macro programming could be said to be supposed to know that the move to > Firebird as default is underway - thus, if the db hasn't yet been migrated, > the macro developer has deliberately planned it that way, and decided to > stick with hsqldb (at least until such time as they decide to migrate to > Firebird out of choice and adapt the macro to deal with that). > > At worst, what happens if no migration occurs ? The user continues to be > able to use the database as before, and the macro continues to work as > planned by the original developer of the macro program. I fully agree. As long as important bug reports concerning the Firebird migration are still open, programmers must have the choice to use the old database where they can be sure their applications work. After the discussions we had a while ago, I am sure the decision to definitely migrate to Firebird will be taken only when these bugs have been resolved, then it will be quite safe to migrate the applications.
I think this is fixed by https://gerrit.libreoffice.org/plugins/gitiles/core/+/77ef0a92b3bd19f836d0fcb2a41af5e643129283%5E%21, Could anyone confirm with a daily build containing the commit ?
I can confirm the bug is fixed. I move it to fixed.