Problem description: When opening a LO-database which links to a Mysql-database, the names of the database and the name of the table (my db only has one table) is not shown correctly (see screenshot), and when clicking on the name of the tabel to open it, it uses that incorrect names in the SQL-query, which of course results in an SQL-error. Steps to reproduce: 1. Open an LO-database in Base, which links to a mysql database. 2. Click on Tables Current behavior: The names of the database and the table have unknown symbols in it, and trying to open a table results in a SQL-error. Expected behavior: Correct names of database and table(s) are shown, and clicking on a table name gives the contents of that table. Operating System: Linux (Other) Version: 4.0.0.0.beta2 Last worked in: 3.6.4.3 release
Created attachment 72044 [details] Screenshot of the erroneous names of databae and table
How do you connect to MySQL? - native LibO connector? - ODBC driver? (what version?) - JDBC driver? (what version?) Do your schema/table names contain non-ASCII characters?
Connection is trough odbc: unixODBC v. 2.2.12-217.1.2 The names of database and table contain only lower capital a-z characters.
That's my fault, I got confused between "byte length" and "character length" for Unicode data in the ODBC API. Will commit a fix shortly.
*** Bug 58578 has been marked as a duplicate of this bug. ***
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=51c8bb3242ad1e8e1a5906c4af2ba94c0252b36e&h=libreoffice-4-0 fdo#58693 ODBC SQLGetData returns byte length, not data size It will be available in LibreOffice 4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2f54f2a4ac508de3984d2865da984b9ecf30f602 fdo#58693 ODBC SQLGetData returns byte length, not data size The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
In the beta2-19-1, downloaded from the OpenSuse build service, the problem is still present (I reported it fro beta2-12)
(In reply to comment #8) > In the beta2-19-1, downloaded from the OpenSuse build service, the problem > is still present (I reported it fro beta2-12) This bug is fixed in LibreOffice 4.0.0.rc1, not in beta2. As you say yourself, you *reported* it for beta2. The changes between SuSE's beta2-12 and beta2-19-1 are only *packaging* changes, they do not contain any "upstream" changes, that is changes in LibreOffice code made by the LibreOffice project. To get our updates/fixes from SuSE, you probably have to wait until they package 4.0.0.rc1. In the meantime, you can get a version with this bug fixed from http://dev-builds.libreoffice.org/daily/libreoffice-4-0/Linux-x86_64_11-Release-Configuration/current/ http://dev-builds.libreoffice.org/daily/libreoffice-4-0/Linux-x86_10-Release-Configuration/current/ The file you need is the one whose name ends with Linux_x86_install-rpm_en-US.tar.gz (plus the langpack and optionally helppack for the languages you want); untar this and you'll get RPMs that you can install; it will install LibreOffice as /opt/lodev4.0/program/soffice.
I downloaded and installed the version you pointed to (it still is a beta2 release, not rc1). I had to remove the existing LODev because of conflicts and "already installed" messages. It isn't getting any better though: now, when I try to open the table, as soon as I type in my password for the sql-database, and press Enter, LO crashes without further notice. Not much extra info when started from the command line: /opt/lodev4.0/program> ./soffice KCrash: Application 'soffice.bin' crashing... KCrash cannot reach kdeinit, launching directly.
(In reply to comment #10) > I downloaded and installed the version you pointed to (it still is a beta2 > release, not rc1). It calls itself beta2, but it is some intermediate state between beta2 and rc1. Sorry for the confusing labeling. > now, when I try to open the table, as > soon as I type in my password for the sql-database, and press Enter, LO > crashes without further notice. That's a different bug, which you are welcome to report in a *new* bug, but please don't reopen this one, unless you reproduce it in a version where it is supposed to be fixed. This being said, did you upgrade all LibreOffice RPMs in lockstep? Not doing so can give such crashes. If you did, as I said, probably a *different* bug.
No need to be sorry! I just mentioned it to be sure I did the right thing. I'm not sure what you mean by 'lockstep'; what I did was removing all LO and LODev entries that existed in my system, then download libreoffice-4-0~2012-12-28_14.40.59_LibO-Dev_4.0.0.0.beta2_Linux_x86-64_install-rpm_en-US.tar.gz libreoffice-4-0~2012-12-28_14.40.59_LibO-Dev_4.0.0.0.beta2_Linux_x86-64_langpack-rpm_nl.tar.gz libreoffice-4-0~2012-12-28_14.40.59_LibO-Dev_4.0.0.0.beta2_Linux_x86-64_helppack-rpm_nl.tar.gz from the location you mentioned, untarred and install all rpm's from these packages (also the suse desktop integration) with 'rpm -Uhv *.rpm'. I think that's the correct procedure? I'll await your answer before entering a new bug, so as to be sure it's not some stupidity on my side.
Hmm, I did not touch the status field of this bug, but I see it's now 'unconfirmed' - is that because of me adding another comment?
(In reply to comment #12) > what I did was removing all LO and > LODev entries that existed in my system, (...) install all rpm's from these > packages (also the suse desktop integration) with 'rpm -Uhv *.rpm'. > I think that's the correct procedure? Yes, that's correct. Then I don't know what is wrong, maybe you found a true new bug. (In reply to comment #13) > Hmm, I did not touch the status field of this bug, but I see it's now > 'unconfirmed' - is that because of me adding another comment? No, adding a new comment usually does not change the status. If you didn't touch the status field (below the "addition comments" box), then I don't know what happened. Closing bug again.
Confirmed fixed on Mac OSX with : Version 4.1.0.0.alpha0+ (Build ID: 989863d849b1e703e78afc413088c3ae5109313) TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2013-01-06_10:52:34 Closing. Alex