Created attachment 57225 [details]
odb file used

I can confirm the buggy behaviour, it is not new to 3.5 though, it has been around since we first released LO, although I can't remember now if I opened a bug report at the time (nobody seems to care much for mysql connection problems, what with the past history, with it being Oracle and all that - unfortunate, but true).

If I find an original bug report, I'll mark this as a duplicate, but confirming in the meantime.

Also, there is a workaround : you can use the native mysql connector instead of ODBC, which does have the added advantage of not suffering from the object limitations of the ODBC driver.

Which other software are you using on Mac via ODBC to gain access to your mysql database ? 

I have also tried the Actual Technologies driver, but that fails too when fetching the records (the table list displays though, so it goes one better than mysql's ODBC driver)
 
http://www.actualtech.com/

but, this is also proprietary, and you have to fork out 35 USD for it, which is probably not everyone's cup of tea (especially if it doesn't work ;-))


Alex

Changed title to better reflect problem, set platform to Mac OSX as it only affects this OS.

Alex

I would add that from trawling various forums related to ODBC on Mac with mysql, it appears that the mysql 32bit ODBC driver is less than innocent in all of these shenanigans, and that most of the problems appear to lie with the driver (that is not to say that LO doesn't have a problem either, but hey). This also makes it even less likely that a developer will spend time trying to solve the issue (I am not a developer btw).


Alex

Same error but with MySQL ODBC. Only show data in Row 41. When try to install LibreOffice MySQL Native, (the 'oxt') it's not prepared for Ubuntu installations.

(In reply to comment #5)
> Same error but with MySQL ODBC. Only show data in Row 41. When try to install
> LibreOffice MySQL Native, (the 'oxt') it's not prepared for Ubuntu
> installations.

Sorry, I don't understand what you mean.

Then you throw in a comment about native mysql connection on Linux, what has that got to do with this bug (nothing as far as I can tell, it certainly isn't an ODBC connector).


Alex

Currently, there is probably no one on the LO dev team who has a Mac and would be prepared to put the time into trying to find out why this doesn't work, and how it could be fixed. Just so you don't get your hopes up too much.

I've never got ODBC to work with LO on Mac. It stopped working anyway with OOo 3.3.0, and it is unlikely to be fixed in the near future.

Alex

A workaround for LO 357 and LO 364 is to use the ODBC driver provided by Actual Technologies, however, it is "pay-for" software.

Be warned though, that LO master 4.1 daily builds currently screw up the display of char/varchar fields with ActualTech's driver, so stick to the older production versions.


Alex

This now works in 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 as WFM.


Alex

Ooops, sorry, it only seems to work with Actual Technologies ODBC driver, so reopening.

Here is the error message with iODBC :
SQL Status: 00000
Error code: -1073750488
[iODBC][Driver Manager]dlopen(/usr/local/lib/libmyodbc5.so, 6): no suitable image found.  Did find:
	/usr/local/lib/libmyodbc5.so: mach-o, but wrong architecture


Alex

Putting Lionel on CC.

(In reply to comment #10)
> Ooops, sorry, it only seems to work with Actual Technologies ODBC driver, so
> reopening.

> Here is the error message with iODBC :
> SQL Status: 00000
> Error code: -1073750488
> [iODBC][Driver Manager]dlopen(/usr/local/lib/libmyodbc5.so, 6): no suitable
> image found.  Did find:
> 	/usr/local/lib/libmyodbc5.so: mach-o, but wrong architecture

The "wrong architecture" suggests a "64bit vs 32bit" (or maybe PPC vs Intel) mixup.

(In reply to comment #12)

 
> The "wrong architecture" suggests a "64bit vs 32bit" (or maybe PPC vs Intel)
> mixup.

Absolutely, and therein lies the problem. Until there is a 64bit LO version for Mac, this problem won't be solved.

Actual Technologies driver is compiled to be universal, so it works with 32 and 64bit applications.

MySQL provides either 32 or 64bit drivers - the 32bit ODBC driver allegedly works with 32 bit LO on a 32bit Mac OSX, i.e. 10.4, 10.5, and 10.6 running in 32bit kernel mode.

Mysql's 64bit driver works on a 64bit OSX, e.g. using isql (which works fine), but is incapable of being loaded by LO 32bit due to the architecture mismatch.


Alex

Update :

I have successfully managed to build a 64bit OSX version of LO master :
Version: 4.2.0.0.alpha0+
Build ID: 22d1beb78a475e4846af945afde1c4d6c263b5d6

Note that 64bit OSX builds are not yet produced by TDF for public consumption, be it as dev daily packages, or stable releases.

With the version above, after entering my login credentials, I can see the list of tables, so this is now WFM.

However, double-clicking on any one of the table entries gives an error message, and the table view mode fails to show any contents. I will enter a separate bug report for that.


Closing this as WFM.

Alex

Hmm, after trying to open up other odbc-connected ODB files, I can actually confirm and reproduce the buggy behaviour.

My previous tests focussed on a connection to the mysql system db itself, which are displayed.

If however, I try and connect to any other ODBC datasource, i.e. a test db, or my usual work db, then the tables are not listed.

This is confirmed by the fact that if I attempt to query the db from the query editor, I get an error message that no database has been selected, which would indicate that the db parameter from the odbc.ini entry is not being explicitly passed to the server upon connection, or else is dropped in some way by LO.

If I go to Tools > SQL, then issue

use mydb

Executes successfully 

Then enter a select query for any table :

Select * from MyTable

and ask for the results to be displayed in the bottom window, the query executes and the results are displayed.



Alex

Note however, that the same problem exists with the isql tool.

Simply connecting to the db from the command line and then trying to execute a select query will result in an error, I have to specify "use mydb" before I can successfully query the db.

So, this may/may not be a limitation of Apple's iodbc implementation, in which case, we can't do much about it.


Alex

And as confirmation of that...

MacBookPro:~ alex$ iodbctest "DSN=mydb;UID=myuser;PWD=mypwd"
iODBC Demonstration program
This program shows an interactive SQL processor
Driver Manager: 03.52.0607.1008
Driver: 05.01.0011 (libmyodbc5.so)

SQL>select * from mytable;
1: SQLExec = [MySQL][ODBC 5.1 Driver][mysqld-5.5.25a-log]No database selected (1046) SQLSTATE=3D000


which is pretty crap, really.


Alex

(In reply to comment #17)


> which is pretty crap, really.
> 


The irony being that with the same setup, exchanging only the db name for the system mysql db, I can directly query the mysql db without having to apply a USE statement...


Alex

Sigh, it's one of those days :

Turned out that the /Library/ODBC/odbc.ini file was missing an entry for the db. After having corrected that, I can now get the list of tables to appear on my db of choice, so resetting as WFM.

There are other problems, such as the fact that all of the tables in the list are marked as Views in the GUI, and I can't actually display any of the information contained in the tables from the GUI. Other bug reports will be used for those problems.

Re-setting as WFM with 64bit LO.


Alex

Forgot to mention that it works with a SystemDSN.


Attempting to connect via any of my UserDSNs displays the same problem as the initial poster.


Alex