Skip to Content.
Sympa Menu

freetds - Re: [freetds] Invalid cursor state when executing 2 SELECTstatements

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Sebastien FLAESCH <sf AT 4js.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Invalid cursor state when executing 2 SELECTstatements
  • Date: Sun, 06 Jan 2008 09:04:16 +0100

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






Archive powered by MHonArc 2.6.24.

Top of Page