The output of lastError().text() is a bit surprising and I have no idea where it comes from. I have tried rebuilding the qtsql module but (as I knew beforehand) it didn't help. The driver is there, and Qt seems able to see it. I have used QtSql in several problems in the past, though maybe never with MSSQL.

I have used many variants of that connection string (client and server variants, and a few others). I went as fas as to using the FreeTDS configured driver name, which also didn't work.

From the command line I can connect using this FreeTDS thing, so I know the server is reachable and accepting connections.

I don't really know if Qt needs this FreeTDS thing when using the QODBC driver. I am just trying at random and nothing seems to work. The fact that the only bit of info I could help appears to be trashed doesn't help in debugging this...

Hi, I also struggled with this some time ago, the problem is that with FreeTDS and db.setDatabaseName() you cannot specify modern style DSNs like you do in Windows with the IP.number etc.
Instead you have use old-style ODBC DSN-names, called a DSN-name like "dsn1".
Then create an odbc.ini file and a .freetds.conf file which refers to that DSN-name.

I have some code that wrote those 2 files for FreeTDS on the Mac and on Ubuntu, can only find the Mac code right nowon my GitHub line 81-123
but I remember it worked on Ubuntu as well.

Where the string "mydsn" is that little header that goes in between brackets in the odbc.ini and FreeTDS files.

This is a variant I have tried, along with many others. I also tried the full DSN in combination with the setUserName() / setPassword() thing, but it didn't help.

And, in any case, I am afraid that that corruption in the lastError() output has something to do with it. For I don't know what reason something in the ODBC chain if failing miserably and I fear that while I don't fix that I am doing nothing but hitting against a wall.

I will be setting a Windows machine at work to test this in the next few days to confirm or discard this theory, but doing the development in Windows is not something I'll be doing so sooner or later I will have to either fix this or re-think my roadmap :P

Hi, I seem to remember getting that same "garbage" output from lastError() when I tried on Ubuntu two years ago.
Anyway, I know I have an working example for Ubuntu 14.04 that prints out some rows from the Northwind database on a SQL Server (and to get it to work i remember I had to it the "fancy way" as you say above).
Later today I'll check my backups and post something. promise :-)

Found the code on my old harddisk: for ODBC to work in Linux, indeed it seems you have to do it the "fancy" way, I mean always write those files ..odbc.ini and .freetds.conf
(Linux is actually slightly simpler than OSX, the files go both into the same home directory).

To test the code, I first installed a fresh Ubuntu 16.04 and then installed unixOBDC and freeTDS:sudo apt-get install unixodbc unixodbc-dev freetds-dev tdsodbc

Installed Qt 5.6, downloaded Qt's source and built the libqsqlodbc.so plugin, placed it together with the other chaps in Qt's ../plugins/sqldrivers subdirectory.

Then I created an empty Qt console app (called ODBCOnLinux :-) in the .pro file I inserted:QT += sql
and this is how main.cpp looks:

Note 1: I didn't have to edit odbc.ini or any other file in /etc or somewhere else.
Note 2: you have to specify where the FreeTDS driver .so file is, in my case with 64-bit Ubuntu it's always /usr/lib/x86_64-linux-gnu/odbc/libtdsodbc.so
Note 3: my dump of all the tables and rows is a bit sloppy, the program will sometimes complain about "column invalid range", this error is by design :-)

By now, I have exactly zero doubt that the problem, whatever it is, lies within qsqlodbc.so.

I have tested many builds, with 4.x, 5.x, up to the latest, I have also downloaded the linux installer (ugh) just to discard some toolchain oddness, gcc version issues, etc.

I have been wandering in another couple forums, to no avail.

The concrete output varies a bit with versions. But I doubt it's relevant. The qt sql bridge is doing something odd that the unixodbc and freetds command line tools don't do. They all work with or without vpn in the middle.

Hi, indeed as you say, your isql works like a charm but libqsqlodbc.so does not :-(
What you can do, compare the outputs of lsof -c isql and lsof -c linuxodbccon to see that they load the same .so files.

You could try my libqsqlodbc,so from my build (Qt 5.6 on Ubuntu 14.04 64-bit) I just zipped and uploaded it to my websitet

Or perhaps Gentoo is allergic to Qt and ODBC? If you have VirtualBox or VMWare you could try downloading Ubuntu and test on that...

I can't remember if I said above that I also tried the binary qt installer, whose binaries are not tied to Gentoo in any way. So, if the issue is with Gentoo, it's is something with deeper roots than just qt.

Trying another distro with a different glibc version might make some sense at this point. That won't be *buntu, though :lol:

Installed Qt 5.6 64-bit.
Then I downloaded my libqsqlodbc.so I built on my Ubuntu 14.04 (because I was too lazy to rebuild it on Gentoo) and placed it in ~/Qt/5.6/gcc_64/plugins/sqldrivers
Now I hit a snag (because I built that on the old 14.04, which only has libodbc.so.1.0.0, not libodbc.so.2.0.0):
In Ubuntu 16.04 there are 3 symbolic links libodbc.so --> libodbc.so.1 --> libodbc.so.2 so that it'll load just fine anyway but emerging unixODBC in Gentoo resulted in just 2 links libodbc.so and libodbc.so.2 :-( So I had to manually create that link:cd /usr/lib64sudo ln -s libodbc.so.2.0.0 libodbc.so.1

One more thing: changing the location of the libtdsodbc driver in my program, for Ubuntu it was:QString sFilename = "/usr/lib/x86_64-linux-gnu/odbc/libtdsodbc.so";
for Gentoo change it to:QString sFilename = "/usr/lib/libtdsodbc.so";

Voila!

Edit: that dependency on libodbc.so.1 was probably the reason my libqsqlodbc.so wouldn't load when you tested it.

@hskoglund, thanks for all the ideas. I have discovered that whatever is happening here, it's a bug in the plugin that Gentoo installs. I have no idea what the problem is, I'll have to dig a bit more, and iron this out a bit in conjunction with the Gentoo developers.

I used ldd on your binary, and found that, indeed, it needs a libodbc.so.1 file, which I just linked as you suggested. After that, my program started to work. I am not doing any fancy thing with config files, I just use the standard files under /etc for odbc and freetds, and it just worked as it should. So, there's clearly some problem with the Gentoo generated libqsqlodbc.so library.

By the way, if you want to try the Gentoo lib out of curiosity, all you need is to enable the odbc USE flag for qtsql, and re-emerge it. If my theory is correct, that one should fail to work.

Just for the sake of completeness, and in case someone like me lands here, I'll add that, even if you can connect, you won't be able to query (other than simple UPDATE statements, it seems). SELECT won't work.

That can be easily overcome by installing freetds-1.0 though, which got added into portage just a few days ago, as opposed to the 0.91 version which is in stable portage.

At least now I can select, let's wait for unions and joins to get into scene :lol: