FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Chad Sikorra wrote:
> I'm trying to figure out if
> the issue I'm having is a Wine issue or a FreeTDS issue. I configured a
> system DSN via ODBCConfig and I tested basic connectivity with the isql
> command and it connects fine. So I setup my application to use that DSN.
> When I launch the application and it attempts to connect using that DSN
> I receive the following error message...
> 
> --------
> SL009
> 
> No columns were bound prior to calling SQLFetch or SQLFetchScroll

That's an odd message.  It's valid: it's documented in Microsoft's MDAC. 
But, oddly enough *not* as a valid code for either SQLFetch or
SQLFetchScroll!  

And there's no requirement to bind any columns before calling SQLFetch or
SQLFetchScroll.  I mean, what does it mean?  

The message is not produced by FreeTDS.  Try scanning the sources for
SL009.  Also, from the log it looks like you're not using 0.82.  Upgrading
might help.  

All that said, though, the log looks odd, too: you're sending a cancel
packet.  Maybe the next level up gets confused. (Or maybe it expects
correct behavior, which it's unlikely to get before FreeTDS 0.82.)   

Here's your SELECT statement: 

> 08:56:29.081172 Sending packet
> 0000 01 01 00 5e 00 00 01 00-73 00 65 00 6c 00 65 00 |...^.... s.e.l.e.|
> 0010 63 00 74 00 20 00 53 00-74 00 61 00 74 00 75 00 |c.t. .S. t.a.t.u.|
> 0020 73 00 20 00 66 00 72 00-6f 00 6d 00 20 00 54 00 |s. .f.r. o.m. .T.|
> 0030 72 00 61 00 63 00 6b 00-65 00 72 00 20 00 77 00 |r.a.c.k. e.r. .w.|
> 0040 68 00 65 00 72 00 65 00-20 00 53 00 74 00 61 00 |h.e.r.e.  .S.t.a.|
> 0050 74 00 75 00 73 00 20 00-3e 00 20 00 30 00       |t.u.s. . >. .0.|

The reply is 4 packets: a header and 3 rows: 
 
> 08:56:29.082553 Received packet
> 0000 81 01 00 00 00 09 00 26-04 06 53 00 74 00 61 00 |.......& ..S.t.a.|
> 0010 74 00 75 00 73 00 d1 04-4d 00 00 00 d1 04 48 00 |t.u.s... M.....H.|
> 0020 00 00 d1 04 7c 00 00 00-fd 10 00 c1 00 03 00 00 |....|... ........|
> 0030 00                     -                        |.|
> 
> 08:56:29.082609 processing result tokens.  marker is  81(TDS7_RESULT)
...
> 08:56:29.082718 processing result tokens.  marker is  d1(ROW)

        Oops: 

> 08:56:35.828772 SQLFreeHandle(3, 0x0x7c1433f8)
> 08:56:35.828831 Sending packet
> 0000 06 01 00 08 00 00 01 00-                        |........|
       ^^
       That's a cancel packet going to the server. 

The handle was freed, but the data keep arriving.  The log doesn't show
the ODBC layer.  I don't know how the rows are being fetched.  

> 08:56:35.828901 tds_process_default_tokens() marker is d1(ROW)
...
> 08:56:35.828982 tds_process_default_tokens() marker is d1(ROW)
...
> 08:56:35.829078 tds_process_default_tokens() marker is d1(ROW) 

        ... and a DONE cancelled ...

> 08:56:35.830209 Received packet
> 0000 fd 20 00 fd 00 00 00 00-00                      |. ...... .|
> 
> 08:56:35.830231 tds_process_end: more_results = 0
>         was_cancelled = 1
>         error = 0
>         done_count_valid = 0
> 08:56:35.830259 tds_process_end() state set to TDS_IDLE
> 08:56:35.830358 SQLFreeHandle(3, 0x0x7c109428)
> 08:56:35.830382 Sending packet

        ... sending another cancel packet ...

> 0000 06 01 00 08 00 00 01 00-       

I'm not sure that's allowed by the protocol.  It's definitely unhelpful,
and  prevented in 0.82: the library won't send a CANCEL packet unless the
connection is in the state of retrieving data.  

Here comes the second acknowledgement:

> 08:56:35.831038 Received packet
> 0000 fd 20 00 fd 00 00 00 00-00                      |. ...... .|
> 
> 08:56:35.831059 tds_process_end: more_results = 0
>         was_cancelled = 1
>         error = 0
>         done_count_valid = 0

A new query: 

> 08:56:35.831762 Sending packet
> 0000 01 01 00 6e 00 00 01 00-53 00 65 00 6c 00 65 00 |...n.... S.e.l.e.|
> 0010 63 00 74 00 20 00 48 00-45 00 41 00 54 00 53 00 |c.t. .H. E.A.T.S.|
> 0020 63 00 68 00 65 00 6d 00-61 00 20 00 46 00 72 00 |c.h.e.m. a. .F.r.|
> 0030 6f 00 6d 00 20 00 48 00-45 00 41 00 54 00 44 00 |o.m. .H. E.A.T.D.|
> 0040 62 00 20 00 57 00 68 00-65 00 72 00 65 00 20 00 |b. .W.h. e.r.e. .|
> 0050 44 00 62 00 4e 00 61 00-6d 00 65 00 20 00 3d 00 |D.b.N.a. m.e. .=.|
> 0060 20 00 27 00 48 00 45 00-41 00 54 00 27 00       | .'.H.E. A.T.'.|
...
> 08:56:35.833038 Received packet
> 0000 81 01 00 00 00 09 00 26-04 0a 48 00 45 00 41 00 |.......& ..H.E.A.|
> 0010 54 00 53 00 63 00 68 00-65 00 6d 00 61 00 d1 04 |T.S.c.h. e.m.a...|
> 0020 da 20 00 00 fd 10 00 c1-00 01 00 00 00          |. ...... .....|
> 
> 08:56:35.833108 processing result tokens.  marker is  81(TDS7_RESULT)
...
> 08:56:35.833231 processing result tokens.  marker is  d1(ROW)

Here we go again, cancelling after row 1 (even though there's only one row
of data):  

> 08:56:36.998665 SQLFreeHandle(3, 0x0x7c142488)
> 08:56:36.998719 Sending packet
> 0000 06 01 00 08 00 00 01 00-                        |........|
...
> 08:56:36.999681 Received packet
> 0000 fd 20 00 fd 00 00 00 00-00                      |. ...... .|
> 
> 08:56:36.999703 tds_process_end: more_results = 0
>         was_cancelled = 1
>         error = 0
>         done_count_valid = 0

And the CANCEL is acknowledged. 

> Does anyone have any ideas/hints as to what may be causing this error
> when launching the application? I have tried using TDS version 4.2 and
> 7.0 with the same results as version 8.0.

Suggestions:

1.  Upgrade.  
2.  Output both the ODBC log and the FreeTDS log to standard output, so
that they're interwoven.  (Probably easier said than done with WINE.) 
That might clarify the state of the driver when the message is produced
(by the DM, I assume).  

HTH.  I'm crossing my fingers that upgrading will do the trick.  

--jkl