FreeTDS Development Group

[Michael Koehmstedt <mykillk AT gmail.com>]

I have been running into a similar problem today as described in this thread.

I am using FreeTDS, Unix ODBC, and ODBC-FDW to be able to access my
Microsoft SQL Server 2008 through my PostgreSQL 9.1 database.
Everything has been successful so far, except that one column always
shows up as an empty column when queried.

I was getting the same issue when using bsqlodbc, it was coming up
empty. Then I saw Frediano's post saying that he had fixed the problem
in the GIT repo. I confirmed that my problematic char(1) column now
displays properly in bsqlodbc after compiling the latest FreeTDS off
GIT.

Since bsqlodbc properly queries the column, I'm almost sure the
problem lies somewhere within ODBC-FDW, and that the issue is very
similar to the issue with bsqlodbc.

So my question, what exactly was changed in the bsqlodbc source to
allow it to properly map a text column?


Regards,
Michael Koehmstedt



> Frediano Ziglio
> Fri Sep 28 03:00:33 EDT 2012
>
>
> I wrongly pushed a patch that fix some issue with characters and
> bsqlodbc in Branch-0.91.
>
> Wrongly just cause was not correctly tested, I reverted some changes.
>
> Mainly:
> - if you want just to get information from row you should get row
> implementation descriptor, not create a new one as the new one would
> have empty information
> - SQLAllocHandle for descriptor wants a connection, not a statement,
> this is the reason for the invalid handle returned
> - SQLFetch can return SQL_NO_TOTAL (usually -4) if can't translate all
> string to the check data[c].len > 0 can be false, I increased buffer
> allocated for string however if string is empty the assert will still
> raise. It would be better to handle correctly SQL_NO_TOTAL.
>
> Frediano

-- 
Michael Koehmstedt