FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2012/9/19 James K. Lowden <jklowden AT freetds.org>:
> On Tue, 18 Sep 2012 19:56:14 +0000
> Tony Esposito <Tony.Esposito AT region10.org> wrote:
>
>> (1) Set my MANPATH so now I can find the man pages for bsqlodbc.
>
> Hurrah!
>
>> (2) Ran bsqlodbc and get the following:
>>
>> user #> bsqlodbc -U dba -P sql -S txeis -D DB246111 -i input.sql -o
>> output.sql -e error.sql
>>
>> Input file input.sql contents:        select * from sr_stu_demo;
>> Output file output.sql contents:  <empty>
>> Error file error.sql contents:          bsqlodbc: error: 100 is an
>> unknown return code for SQLExecute
>
> As I suspected, a missing error message.  But why?
>
> The number 100 has some significance but shouldn't show up in this
> context.  The TDS library can return error 100 to indicate iconv is not
> supported for TDS protocol version 7.3, but you're using TDS 5.0 and
> the error's being returned from SQLExecute, not SQLConnect.
>
> I'm afraid all I can suggest is to use TDSDUMP with the above command
> and, and lets have another look at the output.  The log will show a lot
> of the call stack.  It might yield a clue of where to look.
>
> You have found a bug, by definition.  I think there's something funny
> in your configuration, something you'll easily be able to fix.  The bug
> is that you shouldn't be able to get the system to produce that
> message, no matter what you do.  So I am interested in how it
> happened.
>

No, 100 in ODBC is SQL_NO_DATA. From documentation
SQLExecute/SQLExecDirect should return SQL_NO_DATA if not data are
returned. It seems that MS ODBC never return this value. I think that
I changed (not in 0.91!) our driver to return SQL_NO_DATA according to
MS ODBC. However it's a bug in isql in this case.

Frediano