gmane.comp.db.tds.freetds

Chris Reeves | 21 Aug 19:16

Prepared statements with no parameters exhibit strange behaviour


I noticed some strange behaviour last week when using ODBC to prepare and
execute a statement with no parameters. This could be readily reproduced using
a call sequence along the lines of:
  SQLPrepare(handle, "select * from foo where bar = 1", SQL_NTS);
  while (1) {
    SQLExecute(handle)
    SQLNumResultCols(handle, &nCols)
    printf("Number of columns: %i", nCols);
    while (SQLFetch(handle) != SQL_NO_DATA) {
      // Some code (or no code)
    }
    SQLFreeStmt(handle, SQL_CLOSE)
  }

This call sequence would produce something like:
  Number of columns: 65
  Number of columns: 0 
  Number of columns: 65
  Number of columns: 0 
  Number of columns: 65
  Number of columns: 0 
  Number of columns: 65
  Number of columns: 0 
  ...
assuming it didn't just die with:
08S01 (20004): [unixODBC][FreeTDS][SQL Server]Read from the server failed
on the third call to SQLExecute.

Removing the calls to SQLFetch would eliminate the problem (number of columns

(Continue reading)

headers

ZIGLIO, Frediano, VF-IT | 22 Aug 08:49

Re: Prepared statements with no parameters exhibit strangebehaviour

> 
> I noticed some strange behaviour last week when using ODBC to 
> prepare and
> execute a statement with no parameters. This could be readily 
> reproduced using
> a call sequence along the lines of:
>   SQLPrepare(handle, "select * from foo where bar = 1", SQL_NTS);
>   while (1) {
>     SQLExecute(handle)
>     SQLNumResultCols(handle, &nCols)
>     printf("Number of columns: %i", nCols);
>     while (SQLFetch(handle) != SQL_NO_DATA) {
>       // Some code (or no code)
>     }
>     SQLFreeStmt(handle, SQL_CLOSE)
>   }
> 
> This call sequence would produce something like:
>   Number of columns: 65
>   Number of columns: 0 
>   Number of columns: 65
>   Number of columns: 0 
>   Number of columns: 65
>   Number of columns: 0 
>   Number of columns: 65
>   Number of columns: 0 
>   ...
> assuming it didn't just die with:
> 08S01 (20004): [unixODBC][FreeTDS][SQL Server]Read from the 
> server failed

(Continue reading)

headers

Chris Reeves | 22 Aug 09:59

Re: Prepared statements with no parameters exhibit strangebehaviour

On Fri, Aug 22, 2008 at 08:49:59AM +0200, ZIGLIO, Frediano, VF-IT wrote:
> 
> Applied modified versions of the patches. tds_query_flush_packet was really wrong in
> tds_send_emulated_execute!
> I noted however that probably you are using wrong protocol version. ODBC should use this
> function only on Sybase with some text fields or using a former protocol (4.2). Currently
> you should use protocol version 5.0 for Sybase, 8.0 for mssql2k and 7.0 for mssql < 2k.

I noticed that FreeTDS was using protocol 4.2 when I was debugging all of this
(the prepared statements weren't really prepared and were sent to the server
every time) but I didn't want to confuse matters by including this in the
other message. My task for today was going to be figuring out *why* it was
using protocol 4.2 (this is an MS SQL server). I don't know any way of
changing this using ODBC calls, so what is the correct way of selecting the
protocol version when using ODBC?

Cheers,
    Chris

headers

ZIGLIO, Frediano, VF-IT | 22 Aug 10:32

Re: Prepared statements with no parametersexhibit strangebehaviour

> 
> On Fri, Aug 22, 2008 at 08:49:59AM +0200, ZIGLIO, Frediano, 
> VF-IT wrote:
> > 
> > Applied modified versions of the patches. 
> tds_query_flush_packet was really wrong in
> > tds_send_emulated_execute!
> > I noted however that probably you are using wrong protocol 
> version. ODBC should use this
> > function only on Sybase with some text fields or using a 
> former protocol (4.2). Currently
> > you should use protocol version 5.0 for Sybase, 8.0 for 
> mssql2k and 7.0 for mssql < 2k.
> 
> I noticed that FreeTDS was using protocol 4.2 when I was 
> debugging all of this
> (the prepared statements weren't really prepared and were 
> sent to the server
> every time) but I didn't want to confuse matters by including 
> this in the
> other message. My task for today was going to be figuring out 
> *why* it was
> using protocol 4.2 (this is an MS SQL server). I don't know any way of
> changing this using ODBC calls, so what is the correct way of 
> selecting the
> protocol version when using ODBC?
> 
> Cheers,
>     Chris

(Continue reading)