In LibreOffice Base, starting with 6.2.0.1, it is no longer possible to change the Database connection type in "MySQL (Native)". I used to work with the MySQL jdbc driver, and want to change to the new MySQL Native driver. That option is no longer available in an existing Base file with Edit / Database> / Connection Type... I can create new Base files with the Databse connection type "MySQL (Native)", but I can not change existing Base files.
Created attachment 156034 [details] dropdown options in LO 6163 vs 6201
Could you give a try to last LO version 6.3.3? Indeed, I can see Mysql direct (= native) on Win10 with LO 6.3.3
No repro with Version: 6.3.3.2 Build ID: a64200df03143b798afd1ec74a12ab50359878ed Threads CPU : 8; OS : Mac OS X 10.14.6; UI Render : par défaut; VCL: osx; Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded I see a general entry called MySQL, choosing this and then clicking Next takes you to the choice of connections (ODBC, JDBC, native).
Also tested with Version: 6.2.8.2 Build ID: f82ddfca21ebc1e222a662a32b25c0c9d20169ee Threads CPU : 8; OS : Mac OS X 10.14.6; UI Render : par défaut; VCL: osx; Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded No repro, WFM.
Have seen the same with recent versions and currently on Ubuntu 18.04 with: Version: 6.3.3.2 Build ID: a64200df03143b798afd1ec74a12ab50359878ed CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded There is no other selection from Edit / Database> / Connection Type... Will attach screenshot.
Created attachment 156051 [details] on Ubuntu 18.04 with LO 6.3.3.2
On pc Debian x86-64 with master sources updated today, I could reproduce this. If I create MYSQL/JDBC file then try to change it to Mysql Native, it doesn't appear. Sorry I had misread the initial comment.
Pb is due to this part 118 // skip mysql connection variations. It is handled in another window. 119 if(sURLPrefix.startsWith("sdbc:mysql:") && !sURLPrefix.startsWith("sdbc:mysql:jdbc:")) 120 continue; Commenting this block makes Mysql Native Mysql ODBC appear (see https://cgit.freedesktop.org/libreoffice/core/commit/?id=b2cefc2e36925b4384eb0aea54aa2c6bcfb018a8) Tamás: any thoughts here?
I submitted a patch on gerrit to facilitate discussion: https://gerrit.libreoffice.org/#/c/83547/
There is also a similar bug report pending for the display choice of available MySQL database connections in the mailmerge module. Ideally, everything should be consistent. Currently, we have 3 different displays depending on how the user accesses the list choice of db connections.
For the bug requiring consistency in the listing of available DB connections, see also bug 127665
Dear jnplg, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Hello, I tested the bug today, and I can confirm it is still present. Below is the information from the Help - About LibreOffice : Version: 7.2.2.2 (x64) / LibreOffice Community Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: nl-BE (en_BE); UI: en-US Calc: threaded The bug was present since LO Base 6.2, when the Native MySQL connector became integrated in Base.
Lionel/Alex/Robert: just wondering, what's the purpose to have only 1 Mysql entry, just to limit the number of entries? I mean we could list all the Mysql (and removing the replacing process in the display name, see https://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/dlg/generalpage.cxx?r=14cfff50#560) to have: MySQL (JDBC) MySQL (ODBC) MySQL Connector (or rather "MySQL (Native)" if changing connectivity/registry/mysqlc/org/openoffice/Office/DataAccess/Drivers.xcu ?) and remove the specific Mysql dialog. Alex: what was the pb with mailmerge? (I gave a try but didn't see anything related to MySQL dialog even after having declared a MySQL DB in tools/options, I must have missed it I suppose) (another thing too, should we replace "MySQL" by "MariaDB" for these? I mean for native part at least, it's MariaDB and with the time there will be noticeable differences between MySQL and MariaDB I suppose).
The difference between the listbox while creating a database → connecting to an existing database and changing the connection of an existing database is irritating. I would prefer to get the same listbox while trying to change the connection as it is offered while creating a new database. I would call all the connections as "MariaDB(MySQL)". MariaDB(MySQL) and PostgreSQL are the only databases, which are used with the internal native driver and through JDBC and ODBC. So it is a good idea to limit the entries by setting a subfolder for these three entries for every database.
(In reply to Robert Großkopf from comment #15) > .. > MariaDB(MySQL) and PostgreSQL are the only databases, which are used with > the internal native driver and through JDBC and ODBC. So it is a good idea > to limit the entries by setting a subfolder for these three entries for > every database. Thank you for your feedback Robert. With this patch, LO displays one generic "MYSQL" entry in both cases. diff --git a/dbaccess/source/ui/dlg/generalpage.cxx b/dbaccess/source/ui/dlg/generalpage.cxx index e3bacdefbc73..6d4f99e07436 100644 --- a/dbaccess/source/ui/dlg/generalpage.cxx +++ b/dbaccess/source/ui/dlg/generalpage.cxx @@ -304,6 +304,18 @@ namespace dbaui bool OGeneralPage::approveDatasourceType( ::dbaccess::DATASOURCE_TYPE eType, OUString& _inout_rDisplayName ) { + + switch ( eType ) + { + case ::dbaccess::DST_MYSQL_JDBC: + case ::dbaccess::DST_MYSQL_ODBC: + case ::dbaccess::DST_MYSQL_NATIVE: + _inout_rDisplayName = "MySQL"; + break; + default: + break; + } + if ( eType == ::dbaccess::DST_MYSQL_NATIVE_DIRECT ) { // do not display the Connector/OOo driver itself, it is always wrapped via the MySQL-Driver, if @@ -559,17 +571,6 @@ namespace dbaui bool OGeneralPageWizard::approveDatasourceType( ::dbaccess::DATASOURCE_TYPE eType, OUString& _inout_rDisplayName ) { - switch ( eType ) - { - case ::dbaccess::DST_MYSQL_JDBC: - case ::dbaccess::DST_MYSQL_ODBC: - case ::dbaccess::DST_MYSQL_NATIVE: - _inout_rDisplayName = "MySQL"; - break; - default: - break; - } - return OGeneralPage::approveDatasourceType( eType, _inout_rDisplayName ); } The pb is how to call OMySQLIntroPageSetup for the changing connection case and I must recognize I don't understand the mechanism of RoadmapWizardMachine/wizardmachine/dbwiz/dbwizsetup Lionel: if you got some idea, don't hesitate. As for me, I'm stuck.
(In reply to Julien Nabet from comment #14) > > Alex: what was the pb with mailmerge? (I gave a try but didn't see anything > related to MySQL dialog even after having declared a MySQL DB in > tools/options, I must have missed it I suppose) > From memory, the list choices weren't the same. I would need to check again to see if it has gone away.
(In reply to Julien Nabet from comment #14) > Lionel/Alex/Robert: just wondering, what's the purpose to have only 1 Mysql > entry, just to limit the number of entries? I seem to recall that we did this originally, ie. a single long list of connection possibilities. I don't remember now why the the drill down second step dialog was introduced, probably to make the choice selection more focussed and to differentiate it from general JDBC connections, as it might have been felt that there were too many choices in the initial dialog. If we were to continue down that route, we should consider doing the same for Postgresql and other dB backends such as Sqlite or similar which have multiple connector possibilities. I fear however, that that would only complexify the UI code further. I have no strong opinion either way.
(In reply to Julien Nabet from comment #14) > > Alex: what was the pb with mailmerge? (I gave a try but didn't see anything > related to MySQL dialog even after having declared a MySQL DB in > tools/options, I must have missed it I suppose) Julien, the problem with the available mailmerge datasource list menu is described in bug 127665, and is still there.
(In reply to Alex Thurgood from comment #18) > (In reply to Julien Nabet from comment #14) > > Lionel/Alex/Robert: just wondering, what's the purpose to have only 1 Mysql > > entry, just to limit the number of entries? > > I seem to recall that we did this originally, ie. a single long list of > connection possibilities. > Indeed, the complete list of possibilities was present in LO4162 in the datasource dropdown menu (except for the various postgresql possibilities, as only one was given for that db, i.e. the native connector.) Seems that this whole thing is a bit of a UI mess that was never unified in any meaningful way.
(In reply to Alex Thurgood from comment #19) > ... > Julien, the problem with the available mailmerge datasource list menu is > described in bug 127665, and is still there. Thank you for the pointer! Taking a look at https://bugs.documentfoundation.org/attachment.cgi?id=154552 for mailmerge, it corresponds to the simplest case since there's no entries grouping. But since grouping is wanted, it requires to understand the complicated mechanism that I was talking about in my previous comment.
(In reply to Alex Thurgood from comment #20) > (In reply to Alex Thurgood from comment #18) > > (In reply to Julien Nabet from comment #14) > > > Lionel/Alex/Robert: just wondering, what's the purpose to have only 1 Mysql > > > entry, just to limit the number of entries? > > > > I seem to recall that we did this originally, ie. a single long list of > > connection possibilities. > > > > Indeed, the complete list of possibilities was present in LO4162 in the > datasource dropdown menu (except for the various postgresql possibilities, > as only one was given for that db, i.e. the native connector.) > > Seems that this whole thing is a bit of a UI mess that was never unified in > any meaningful way. If we consider the 3 options of MySQL: 1) "MySQL ODBC": it goes to the same screen as choosing "ODBC" and there's no specific ODBC driver for MySQL in connectivity/source/drivers so could be removed 2) "Connect Directly" the only one which should remain and be renamed with the name suggested by Robert, "MariaDB (MySQL)" 3) MySQL JDBC" which has indeed a specific driver in connectivity/source/drivers/mysql_jdbc Reading https://en.wikipedia.org/wiki/Java_Database_Connectivity, there are 4 types of JDBC drivers: " Type 1 that calls native code of the locally available ODBC driver. (Note: In JDBC 4.2, JDBC-ODBC bridge has been removed[9]) Type 2 that calls database vendor native library on a client side. This code then talks to database over the network. Type 3, the pure-java driver that talks with the server-side middleware that then talks to the database. Type 4, the pure-java driver that uses database native protocol. " so I suppose MySQL JDBC corresponds to the second or the third driver. Now, let's pause here. Looking at git history of connectivity/source/drivers/mysql_jdbc/YUsers.cxx I saw this: Revert removal of mysql jdbc connector And also make some minor fixes so it cooperates with the new mysqlc library. ... -rw-r--r-- connectivity/registry/mysql_jdbc/org/openoffice/Office/DataAccess/Drivers.xcu 249 -rw-r--r-- connectivity/source/drivers/mysql_jdbc/YCatalog.cxx 133 -rw-r--r-- connectivity/source/drivers/mysql_jdbc/YColumns.cxx 74 -rw-r--r-- connectivity/source/drivers/mysql_jdbc/YDriver.cxx 435 -rw-r--r-- connectivity/source/drivers/mysql_jdbc/YTable.cxx 336 -rw-r--r-- connectivity/source/drivers/mysql_jdbc/YTables.cxx 216 -rw-r--r-- connectivity/source/drivers/mysql_jdbc/YUser.cxx 324 -rw-r--r-- connectivity/source/drivers/mysql_jdbc/YUsers.cxx 101 -rw-r--r-- connectivity/source/drivers/mysql_jdbc/YViews.cxx 146 -rw-r--r-- connectivity/source/drivers/mysql_jdbc/Yservices.cxx 66 -rw-r--r-- connectivity/source/drivers/mysql_jdbc/mysql_jdbc.component 26 ... First I thought there were indeed mysql_jdbc and they have been removed by error but I noticed this: https://cgit.freedesktop.org/libreoffice/core/commit/?id=26b40fcfc67480e75bd9959b0c5cb9db10fdf6a1 Moving mysqlc into connectivity as a library Additionally I erased the remains of the old mysql C++ connector. Also update the code where the clang plugins were unhappy after moving the mysqlc module. Remove mysql-cpp-connector external. ... -rw-r--r-- connectivity/source/drivers/mysql/YCatalog.cxx 138 -rw-r--r-- connectivity/source/drivers/mysql/YColumns.cxx 78 -rw-r--r-- connectivity/source/drivers/mysql/YDriver.cxx 492 -rw-r--r-- connectivity/source/drivers/mysql/YTable.cxx 356 -rw-r--r-- connectivity/source/drivers/mysql/YTables.cxx 216 -rw-r--r-- connectivity/source/drivers/mysql/YUser.cxx 320 -rw-r--r-- connectivity/source/drivers/mysql/YUsers.cxx 105 -rw-r--r-- connectivity/source/drivers/mysql/YViews.cxx 151 -rw-r--r-- connectivity/source/drivers/mysql/Yservices.cxx 69 -rw-r--r-- connectivity/source/drivers/mysql/mysql.component 26 ... So the same files but instead of connectivity/source/drivers/mysql, there were then in connectivity/source/drivers/mysql_jdbc I thought it was the remnant of an ancient MySQL native connector then I noticed getJavaDriverClass in mysql_jdbc/YDriver.cxx In brief, first I wanted to simplify all this by displaying the 3 MySQL entries but it seems better to have a list not too long, then I thought we could remove these 2 extra MySQL entries and JDBC one isn't possible. Is it really useful to have this last one, I suppose it provides a bit more of features than the pure JDBC driver. Also, I've just realized that removing this part would break all the existing odb files which use this driver. So back to the mess with the intermediary MySQL page, roadmachine, etc. :-(
(In reply to Julien Nabet from comment #22) > > In brief, first I wanted to simplify all this by displaying the 3 MySQL > entries but it seems better to have a list not too long, then I thought we > could remove these 2 extra MySQL entries and JDBC one isn't possible. Is it > really useful to have this last one, I suppose it provides a bit more of > features than the pure JDBC driver. Also, I've just realized that removing > this part would break all the existing odb files which use this driver. > So back to the mess with the intermediary MySQL page, roadmachine, etc. :-( Ouch ! FWIW, the old MySQL-JDBC specific set up dialog used to fetch the driver name automatically - I'm guessing that this is where that reference in YDriver.cxx is supposed to be called, but I'm not sure that it still does this ? (need to check). This is a bit of a pickle with no easy get out :-(
Dear Jean-Paul, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Hello QA Team, I did a new test today, and the problem is still present. Here is the LibreOffice system info : Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: nl-BE (en_BE); UI: en-US Calc: CL threaded The issue is a regression, since it was not present in version 6.1.6.3. The issue first appeared in version 6.2.0.1 and is still present today. It would be great to have the "native connector" to MariaDB and MySQL (which is IMHO the best connector by far !) included is the dropdown list !
(In reply to Jean-Paul from comment #25) > > The issue is a regression, since it was not present in version 6.1.6.3. It wasn't present in LO before 6.2, because the direct connection wasn't part of LO. Up to LO 6.2 you had to install an extension to get direct connection to MariaDB/MySQL. Have a look here: https://wiki.documentfoundation.org/ReleaseNotes/6.2 A new feature couldn't be a regression. The behavior has been introduced with this new feature.