Description: I am using the database tool and I connected to MySql database I got a list of schemas and tables inside any schema not as in the real world Actual Results: in correct table list Expected Results: a correct table list Reproducible: Always User Profile Reset: No Additional Info: look images
Created attachment 180541 [details] images inside the zip the schemas list is not the same as in the MySql tool the table list is incorrect there is an addition to any table name the 0.0 at the start of any table name, from where it comes?
What connection do you use? Direct connection? ODBC? JDBC? What's the precise server Mysql/MariaDB version? Just for the record, we use MariaDB (the Mysql fork) connector. Is it a new behavior (after some LO upgrade)? Do you reproduce this with any Mysql database or just some specific ones? Robert/Alex: thought you might be interested in this one. I never saw this kind of "prefix behavior".
Connection - Direct connection Server - 5.7.26 MySql community server New behavior - No, After installation, I tried to use the product, and on the first time and all later tries I got the same result (with errors). Any Mysql database - all my databases
[Automated Action] NeedInfo-To-Unconfirmed
Which version of LO do you use? Won't get such a "prefix" with Version: 7.3.4.1 / LibreOffice Community Build ID: 13668373362b52f6e3ebcaaecb031bd59a3ac66b CPU threads: 6; OS: Linux 5.3; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded connecting to MariaDB on OpenSUSE 15.3, 10.5.15-MariaDB
Version: 7.3.3.2 (x64) / LibreOffice Community Build ID: d1d0ea68f081ee2800a922cac8f79445e4603348 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: he-IL (he_IL); UI: en-US Calc: threaded
Are the schema located on a remote, web hosting server, or a VPS ? The numbers in front that you point out seem to indicate some kind of versioning? I don't see the issue using a direct connection (native mysql/mariadb connector) on a locally hosted mysql instance (8.0.27) with Version: 7.3.1.3 / LibreOffice Community Build ID: a69ca51ded25f3eefd52d7bf9a5fad8c90b87951 CPU threads: 8; OS: Mac OS X 12.2.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
My server and schema are on my local computer I just made another test with a connection through JDBC driver and the result is the same but I think I will give you a clue after I looked at the error message Table 'webstore-2.0.0.adv_board_base' doesn't exist and I think the problem is the size of the table name 'webstore-2.0.0.adv_board_base' is the full table name and this is the partially error table name 0.0.adv_board_base the missing part is "webstore-2." from the whole name
Furthermore please look at the image I attached it looks like there is a new schema named webstore-2 but it is not true my schema name is webstore-2.0.0 and LibreOffice part the name of the table between un existing schema name and the wrong table name the real name of the table is webstore-2.0.0.The_Table_name and in the error the schema name is webstore-2 (no such schema in my database) the table name is 0.0.The_Table_name (no such table in my database)
Created attachment 180546 [details] schema and table name apart
Have tested with a database name, which contains a dot: MyTest.1.0 It will be shown as database MyTest and the tables inside this database will appear with 1.0Table1 1.0Table2 This will happen with direct connection and JDBC-connection. Will test it also with ODBC, but haven't installed it at this moment. Could connect to the database in the right way with phpMyAdmin. Seems LO sees the first dot as separator between database name and table name.
Gotta love our schema string parser code :-/
It is still less expensive and less dangerous from the bugs in the list here https://www.geeksforgeeks.org/10-famous-bugs-in-the-computer-science-world/
Sounds like something not quite right in connectivity/source/drivers/mysqlc/mysqlc_databasemetadata.cxx ? Lines 834-843: OUString query = buffer.makeStringAndClear(); // TODO use prepared stmt instead // TODO escape schema, table name ? query = query.replaceFirst("?", schemaPattern); query = query.replaceFirst("?", tableNamePattern); Reference<XStatement> statement = m_rConnection.createStatement(); Reference<XResultSet> rs = statement->executeQuery(query); return rs;
Here's a bt showing that at the beginning, schema name is ok: #0 dbtools::impl_doComposeTableName(com::sun::star::uno::Reference<com::sun::star::sdbc::XDatabaseMetaData> const&, rtl::OUString const&, rtl::OUString const&, rtl::OUString const&, bool, dbtools::EComposeRule) (_rxMetaData=uno::Reference to (connectivity::mysqlc::ODatabaseMetaData *) 0x4c47498, _rCatalog="def", _rSchema="test.00", _rName="test", _bQuote=false, _eComposeRule=dbtools::EComposeRule::InDataManipulation) at connectivity/source/commontools/dbtools.cxx:833 #1 0x00007f8aa5795b19 in dbtools::composeTableName(com::sun::star::uno::Reference<com::sun::star::sdbc::XDatabaseMetaData> const&, rtl::OUString const&, rtl::OUString const&, rtl::OUString const&, bool, dbtools::EComposeRule) (_rxMetaData=uno::Reference to (connectivity::mysqlc::ODatabaseMetaData *) 0x4c47498, _rCatalog="def", _rSchema="test.00", _rName="test", _bQuote=false, _eComposeRule=dbtools::EComposeRule::InDataManipulation) at connectivity/source/commontools/dbtools.cxx:1292 #2 0x00007f8aa585f752 in connectivity::sdbcx::OCatalog::buildName(com::sun::star::uno::Reference<com::sun::star::sdbc::XRow> const&) (this=0x4c36e70, _xRow=uno::Reference to (connectivity::mysqlc::OResultSet *) 0x4c7c878) at connectivity/source/sdbcx/VCatalog.cxx:181 #3 0x00007f8aa585f87b in connectivity::sdbcx::OCatalog::fillNames(com::sun::star::uno::Reference<com::sun::star::sdbc::XResultSet>&, std::__debug::vector<rtl::OUString, std::allocator<rtl::OUString> >&) (this=0x4c36e70, _xResult=uno::Reference to (connectivity::mysqlc::OResultSet *) 0x4c7c870, _rNames=std::__debug::vector of length 28, capacity 40 = {...}) at connectivity/source/sdbcx/VCatalog.cxx:193 #4 0x00007f8a96bfa225 in connectivity::mysqlc::Catalog::refreshTables() (this=0x4c36e70) at connectivity/source/drivers/mysqlc/mysqlc_catalog.cxx:32 Now the pb arises at this point connectivity/source/commontools/dbtools.cxx 832 if ( !_rSchema.isEmpty() && aNameComps.bSchemas ) 833 { 834 aComposedName.append( _bQuote ? quoteName( sQuoteString, _rSchema ) : _rSchema ); 835 aComposedName.append( "." ); 836 } _bQuote is false so a dot is added in aComposedName and for a schema call "test.00" we get here: "test.00." obviously any caller which parses this can't know that the beginning of the table name is after the second dot and not after first dot. It just reminds me this patch https://gerrit.libreoffice.org/c/core/+/128579 with Lionel's comments. I struggled some time to make maximum things on mysqlc to work but gave up and try to provide some minimal so with schemas or tables which don't include a dot since it's a kind of special character. Now I'm far from being an expert or perhaps I missed something obvious, anyway if someone knows how to fix this, you're welcome of course! :-) Can't help here=>uncc myself.
Have tried a little bit more. "MyTest.1.0" is the database name "Table" is the table name "MyTest" as database will appear with "1.0.Table" and couldn't show the content. Seems GUI will give "MyTest.1.0.Table" as table name. "MyTest.1.0" will appear also. But GUI won't show any table there. Query with SELECT * FROM "MyTest.1.0"."Table" will show the content of the table. But the table will appear write protected. So you could contact to the tables trough queries, but you couldn't add any data without using tools → SQL or using macro code.
Only to complete this: ODBC connection will give the same buggy behavior in LO.
(In reply to Julien Nabet from comment #15) > > It just reminds me this patch https://gerrit.libreoffice.org/c/core/+/128579 > with Lionel's comments. The bug with the dot appears also in LO 6.4.0.3. This patch had been submitted later, so it would have nothing to do with the buggy behavior.
Think you're on the right track here. That append probably shouldn't happen here, but how to avoid that it does for this use case?
Think this isn't a specific MySQL driver problem, because it will appear in ODBC, JDBC and with direct connection. It doesn't appear, for example, in Firebird, because Firebird will only connect to one database and won't show other databases in pane "Tables". It doesn't appear in PostgreSQL, because there is a schema name like "public", which will separate database name and table name.
Dear Shlomo belleli, 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