[freetds] Invalid cursor state when executing 2 SELECTstatements
Sebastien FLAESCH
sf at 4js.com
Sun Jan 6 03:04:16 EST 2008
Hello Frediano,
Frediano Ziglio wrote:
> Il giorno gio, 03/01/2008 alle 15.09 +0100, Sebastien FLAESCH ha
> scritto:
>> Hi all and happy new year.
>>
>> Just started to play again with the latest snapshot.
>>
>> I believe there is a problem when binding SQL_C_TYPE_TIMESTAMP + SQL_TYPE_TIMESTAMP parameters.
>>
>> Looking at the SQL Profiler output, I see that values are enclosed in duplicated quotes:
>>
>> ''2008-01-03 00:00:00.000''
>>
>> I guess it should be:
>>
>> '2008-01-03 00:00:00.000'
>>
>
> Quite strange... our driver should not quote anything but pass date in
> binary format.
Note it's the output of the SQL Profiler I am talking about... maybe this output is just wrong (buggy).
I will give a try on Monday with the new FreeTDS sources.
Maybe you better wait a bit before releasing 0.65:
If experienced more problem with other tests but did not investigate further as the timstamp
problem had to be solved first to run all tests properly.
I will spend some hours this week to check this.
Anyway, thanks for your fast answer.
Seb
>
>> Attached an ODBC sample to reproduce.
>>
>
> It give me another error and I fixed a small issue calling sp_cursoropen
> (just committed src/tds/query.c) but after fixing this it run correctly.
>
>> Note that even if the '' duplicated quotes are replaced by a singular quote, I still get an error
>> when executed the sp_cursoropen text by hand (copied from the Profiler output):
>>
>> Msg 137, Level 15. State 2, Line 1
>> Must declare the scalar variable "@P1".
>>
>
> Yes, this was due to the missing flag calling sp_cursoropen... I don't
> understand why no-test raised this problem...
> Perhaps we don't have any test with cursor and parameters... (TODO for
> me). Also I should check for SQLExecDirect (with cursor and parameters).
>
>> Note also that SQL_TYPE_TIMESTAMP params must be bound with a precision of 23 with SQL Server ODBC.
>> See example.
>>
>> Yours,
>> Seb
>>
>
> In this case I think precision is ignored. You are using a binary
> format, specifying SQL_TYPE_TIMESTAMP always use the maximun precision
> handled by server.
>
> freddy77
>
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>
More information about the FreeTDS
mailing list