[freetds] Invalid cursor state when executing 2 SELECT statements

[Sebastien FLAESCH]

Dear all,

I just want to:

SQLPrepare(stmt1, "SELECT ...");
SQLPrepare(stmt2, "SELECT ...");
SQLExecute(stmt1);
SQLExecute(stmt2);

But second SQLExecute() returns "Invalid cursor state".

I must either issue an SQLFetch() or SQLCloseCursor() with the first statement
to be able to execute the second one.

Is this a known limitation of the FreeTDS ODBC driver?

Thanks
Seb

[Sebastien FLAESCH]

Dear all,
(hope it helps to send such little test programs in this mailing list).

Attached a little test program executing 2 statements concurrently.

For now with FreeTDS 0.65 I get:

Error -1 at: SQLExecute 2
Diagnostic info:
SQL State: 24000
SQL code : 0
Message : [FreeTDS][SQL Server]Invalid cursor state

When I run the same program with SQL Native Client, I get following output:

>> Fetch from 1: [aaa]
>> Fetch from 2: [aaa]

Note that you must set a statement attribute like:

SQL_ATTR_CURSOR_SENSITIVITY, (SQLPOINTER) SQL_SENSITIVE

or:

SQL_ATTR_CONCURRENCY, (SQLPOINTER) SQL_CONCUR_LOCK

... to get sp_cursor* driven cursors, as you probably know.

It's certainly a good idea to test all possible statement attributes you can
set with ODBC, and check what SQL Native Client sends to the server...

There are a couple of sp_cursoroption calls you should take care of.

Seb

Sebastien FLAESCH wrote:
> Dear all,
>
> I just want to:
>
> SQLPrepare(stmt1, "SELECT ...");
> SQLPrepare(stmt2, "SELECT ...");
> SQLExecute(stmt1);
> SQLExecute(stmt2);
>
> But second SQLExecute() returns "Invalid cursor state".
>
> I must either issue an SQLFetch() or SQLCloseCursor() with the first statement
> to be able to execute the second one.
>
> Is this a known limitation of the FreeTDS ODBC driver?
>
> Thanks
> Seb
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: odbctest12.c
Type: text/x-csrc
Size: 7142 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/freetds/attachments/20071217/110a9039/attachment.bin

[ZIGLIO, Frediano, VF-IT]

>
> Dear all,
> (hope it helps to send such little test programs in this
> mailing list).
>
> Attached a little test program executing 2 statements concurrently.
>
> For now with FreeTDS 0.65 I get:
>
> Error -1 at: SQLExecute 2
> Diagnostic info:
> SQL State: 24000
> SQL code : 0
> Message : [FreeTDS][SQL Server]Invalid cursor state
>
> When I run the same program with SQL Native Client, I get
> following output:
>
> >> Fetch from 1: [aaa]
> >> Fetch from 2: [aaa]
>
> Note that you must set a statement attribute like:
>
> SQL_ATTR_CURSOR_SENSITIVITY, (SQLPOINTER) SQL_SENSITIVE
>
> or:
>
> SQL_ATTR_CONCURRENCY, (SQLPOINTER) SQL_CONCUR_LOCK
>
> ... to get sp_cursor* driven cursors, as you probably know.
>
> It's certainly a good idea to test all possible statement
> attributes you can
> set with ODBC, and check what SQL Native Client sends to the server...
>
> There are a couple of sp_cursoroption calls you should take care of.
>
> Seb
>

Well...
step 1. Add tests to out unittests... done, see
http://freetds.cvs.sourceforge.net/freetds/freetds/src/odbc/unittests/?s
ortby=date#dirlist
step 2. Do tests work? No...
step 2. See how tests works under Windows. I used MS ODBC (no Native)
with mssql2k

start test cursor3.exe
odbctest
--------

connection parameters:
server: 'TESTSRV'
user: 'test'
password: '????'
database: 'test'
use test
>> Fetch from 1: [aaa]
>> Fetch from 2: [aaa]
ok test cursor3.exe
start test cursor4.exe
odbctest
--------

connection parameters:
server: 'TESTSRV'
user: 'test'
password: '????'
database: 'test'
use test
>> New value after update = [xxx] (should be [xxx])
ok test cursor4.exe
start test cursor5.exe
odbctest
--------

connection parameters:
server: 'TESTSRV'
user: 'test'
password: '????'
database: 'test'
use test
>> fetch 3 0 : 3 [ccc ]
>> fetch 4 0 : 2 [bbb ]
>> fetch 4 0 : 1 [aaa ]
>> fetch 4 0 : no data found
>> fetch 1 0 : 1 [aaa ]
>> fetch 1 0 : 2 [bbb ]
>> fetch 1 0 : 3 [ccc ]
>> fetch 1 0 : no data found
>> fetch 2 0 : 1 [aaa ]
>> fetch 1 0 : 2 [bbb ]
>> fetch 1 0 : 3 [ccc ]
>> fetch 5 3 : 3 [ccc ]
>> fetch 6 -2 : 1 [aaa ]
>> fetch 6 -2 : no data found
>> fetch 6 5 : no data found
ok test cursor5.exe

Now, why our tests fails... It seems that the combination you use to
setup cursor is not accepted by out driver... problem 2 (problem 1 is
prepared cursors).

I think I have to check how attributes change in MS ODBC... perhaps
setting SENSITIVITY change also CURSOR_TYPE ??

freddy77

[Sebastien FLAESCH]

Hi Frediano,

First, thanks a lot for looking at this cursor issue!

ZIGLIO, Frediano, VF-IT wrote:
> I think I have to check how attributes change in MS ODBC... perhaps
> setting SENSITIVITY change also CURSOR_TYPE ??

As I wrote in a previous mail, you should test all possible combinations
of SQL Statement handle attributes with the MS ODBC MDAC dribver, and see
in the SQL Server Profiler trace what sp_cursor* calls it generates.

Resource in SQL Server 2005 MSDN (you probably know about this link):

http://msdn2.microsoft.com/en-us/library/ms130794.aspx

...

We do use the following SQLSetStmtAttr() attributes:

For scrollable cursors:

SQL_ATTR_CURSOR_SCROLLABLE, SQL_SCROLLABLE
SQL_ATTR_CURSOR_SENSITIVITY, SQL_INSENSITIVE

For SELECT FOR UPDATE cursors (forward only):

SQL_ATTR_CONCURRENCY, SQL_CONCUR_LOCK

For normal cursors, to get "Fast-forward cursors" (MSSQL specific attribute):

SQL_SOPT_SS_CURSOR_OPTIONS, SQL_CO_FFO

In some situations, to force server to prepare (MSSQL specific attribute):

SQL_SOPT_SS_DEFER_PREPARE, SQL_DP_OFF

We always set the cursor name with:

SQLSetCursorName(...) => that generates a sp_cursoroption call I believe.

We do also use array-fetch / column-wise binding (SQL_ATTR_ROW_BIND_TYPE,
SQL_BIND_BY_COLUMN) but that's probably another topic...

...

As a side note you may also install / test with SQL Server 2005 and the new
SQL Native Client driver...

Bye
Seb

ZIGLIO, Frediano, VF-IT wrote:
>> Dear all,
>> (hope it helps to send such little test programs in this
>> mailing list).
>>
>> Attached a little test program executing 2 statements concurrently.
>>
>> For now with FreeTDS 0.65 I get:
>>
>> Error -1 at: SQLExecute 2
>> Diagnostic info:
>> SQL State: 24000
>> SQL code : 0
>> Message : [FreeTDS][SQL Server]Invalid cursor state
>>
>> When I run the same program with SQL Native Client, I get
>> following output:
>>
>> >> Fetch from 1: [aaa]
>> >> Fetch from 2: [aaa]
>>
>> Note that you must set a statement attribute like:
>>
>> SQL_ATTR_CURSOR_SENSITIVITY, (SQLPOINTER) SQL_SENSITIVE
>>
>> or:
>>
>> SQL_ATTR_CONCURRENCY, (SQLPOINTER) SQL_CONCUR_LOCK
>>
>> ... to get sp_cursor* driven cursors, as you probably know.
>>
>> It's certainly a good idea to test all possible statement
>> attributes you can
>> set with ODBC, and check what SQL Native Client sends to the server...
>>
>> There are a couple of sp_cursoroption calls you should take care of.
>>
>> Seb
>>
>
> Well...
> step 1. Add tests to out unittests... done, see
> http://freetds.cvs.sourceforge.net/freetds/freetds/src/odbc/unittests/?s
> ortby=date#dirlist
> step 2. Do tests work? No...
> step 2. See how tests works under Windows. I used MS ODBC (no Native)
> with mssql2k
>
> start test cursor3.exe
> odbctest
> --------
>
> connection parameters:
> server: 'TESTSRV'
> user: 'test'
> password: '????'
> database: 'test'
> use test
>>> Fetch from 1: [aaa]
>>> Fetch from 2: [aaa]
> ok test cursor3.exe
> start test cursor4.exe
> odbctest
> --------
>
> connection parameters:
> server: 'TESTSRV'
> user: 'test'
> password: '????'
> database: 'test'
> use test
>>> New value after update = [xxx] (should be [xxx])
> ok test cursor4.exe
> start test cursor5.exe
> odbctest
> --------
>
> connection parameters:
> server: 'TESTSRV'
> user: 'test'
> password: '????'
> database: 'test'
> use test
>>> fetch 3 0 : 3 [ccc ]
>>> fetch 4 0 : 2 [bbb ]
>>> fetch 4 0 : 1 [aaa ]
>>> fetch 4 0 : no data found
>>> fetch 1 0 : 1 [aaa ]
>>> fetch 1 0 : 2 [bbb ]
>>> fetch 1 0 : 3 [ccc ]
>>> fetch 1 0 : no data found
>>> fetch 2 0 : 1 [aaa ]
>>> fetch 1 0 : 2 [bbb ]
>>> fetch 1 0 : 3 [ccc ]
>>> fetch 5 3 : 3 [ccc ]
>>> fetch 6 -2 : 1 [aaa ]
>>> fetch 6 -2 : no data found
>>> fetch 6 5 : no data found
> ok test cursor5.exe
>
> Now, why our tests fails... It seems that the combination you use to
> setup cursor is not accepted by out driver... problem 2 (problem 1 is
> prepared cursors).
>
> I think I have to check how attributes change in MS ODBC... perhaps
> setting SENSITIVITY change also CURSOR_TYPE ??
>
> freddy77
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>

[ZIGLIO, Frediano, VF-IT]

>
> Hi Frediano,
>
> First, thanks a lot for looking at this cursor issue!
>
> ZIGLIO, Frediano, VF-IT wrote:
> > I think I have to check how attributes change in MS ODBC... perhaps
> > setting SENSITIVITY change also CURSOR_TYPE ??
>
> As I wrote in a previous mail, you should test all possible
> combinations
> of SQL Statement handle attributes with the MS ODBC MDAC
> dribver, and see
> in the SQL Server Profiler trace what sp_cursor* calls it generates.
>

I prefer network trace (I used so lot that I can read easier that...)
however we would get same results.
I wrote another small test, attributes.c derived from descrivecol.c that
test for statement attributes. It's script based, so you can extend it
changing attributes.in
(http://freetds.cvs.sourceforge.net/freetds/freetds/src/odbc/unittests/a
ttributes.in?revision=1.1&view=markup) which currently contains

# some cursor attributes
odbc 3
reset

attr SQL_ATTR_CURSOR_TYPE SQL_CURSOR_FORWARD_ONLY
attr SQL_ATTR_CURSOR_SCROLLABLE SQL_NONSCROLLABLE
attr SQL_ATTR_CONCURRENCY SQL_CONCUR_READ_ONLY
attr SQL_ATTR_CURSOR_SENSITIVITY SQL_INSENSITIVE

set SQL_ATTR_CURSOR_SENSITIVITY SQL_SENSITIVE

attr SQL_ATTR_CURSOR_TYPE SQL_CURSOR_FORWARD_ONLY
attr SQL_ATTR_CURSOR_SCROLLABLE SQL_NONSCROLLABLE
attr SQL_ATTR_CONCURRENCY SQL_CONCUR_ROWVER
attr SQL_ATTR_CURSOR_SENSITIVITY SQL_SENSITIVE

in other works... check initial state of 4 attributes than change
sensitivity and test how these attributes change. This test pass using
MS ODBC so you can see:
- sensitivity is by default INSENSITIVE while our driver do not support
this attribute. I honestly don't know who to support it... place cursors
inside a transaction or use some flags? I don't see any flags under
http://jtds.sourceforge.net/apiCursors.html#_sp_cursoropen.
- MS ODBC transparently change concurrency from READ_ONLY to ROWVER...
interensting cause in our driver we correctly check if we have to use
cursors using

if (stmt->attr.cursor_type != SQL_CURSOR_FORWARD_ONLY ||
stmt->attr.concurrency != SQL_CONCUR_READ_ONLY)

Now... a step forward. As said there are no prepared cursors that is at
line 3004 we should have a similar check and similar code. Also we need
to add tds_cursorprepare and similar (not that difficult however...). I
think that _SQLExecute is becoming too long...


Oh my god, odbc.c is 3 weeks old! I think either
- I'm too busy doing other stuff
- I'm becaming less paranoid
- it's too stable!
(I think a mix of all...)


>
> Resource in SQL Server 2005 MSDN (you probably know about this link):
>
> http://msdn2.microsoft.com/en-us/library/ms130794.aspx
>
> ...
>
> We do use the following SQLSetStmtAttr() attributes:
>
> For scrollable cursors:
>
> SQL_ATTR_CURSOR_SCROLLABLE, SQL_SCROLLABLE
> SQL_ATTR_CURSOR_SENSITIVITY, SQL_INSENSITIVE
>

sensitivity not supported...

> For SELECT FOR UPDATE cursors (forward only):
>
> SQL_ATTR_CONCURRENCY, SQL_CONCUR_LOCK
>

supported but only for SQLExecDirect (SQLPrepare/SQLExecute see above)

> For normal cursors, to get "Fast-forward cursors" (MSSQL
> specific attribute):
>
> SQL_SOPT_SS_CURSOR_OPTIONS, SQL_CO_FFO
>

Mmmm... probably they enable some flags calling sp_cursor** functions.

> In some situations, to force server to prepare (MSSQL
> specific attribute):
>
> SQL_SOPT_SS_DEFER_PREPARE, SQL_DP_OFF
>

This should just make prepare returning success (and don't prepare) that
wait first SQLExecute for preparing. This help cause you are sure to
have parameters binded. I always recommend to bind parameters BEFORE
SQLPrepare, some SQLPrepare implementation require parameters and
prepare two time (one with dummy parameters and another with real
parameters).

> We always set the cursor name with:
>
> SQLSetCursorName(...) => that generates a
> sp_cursoroption call I believe.
>

yes, in odbc.c

tds_alloc_cursor(tds, tds_dstr_cstr(&stmt->cursor_name),
tds_dstr_len(&stmt->cursor_name), stmt->query, strlen(stmt->query));

cursor has names (and yes, it use sp_cursoroption, see
tds_cursor_setname in query.c)

> We do also use array-fetch / column-wise binding
> (SQL_ATTR_ROW_BIND_TYPE,
> SQL_BIND_BY_COLUMN) but that's probably another topic...
>
> ...
>

Yes, there is support in 0.64... but if you have some tests feel free to
send. It seems to be small issues with 0.64 and multiple parameters
(there is a bug at SF)

> As a side note you may also install / test with SQL Server
> 2005 and the new
> SQL Native Client driver...
>

I did some test with Native Client mainly to add TDS 9 support but your
tests success even with normal MS ODBC so I think they can wait... you
know, I'm only a man...

freddy77

[ZIGLIO, Frediano, VF-IT]

>
> Hi Frediano,
>
> First, thanks a lot for looking at this cursor issue!
>

I just committed a patch to CVS... all tests you sent me are
incorporated and working as expected!

> ZIGLIO, Frediano, VF-IT wrote:
> > I think I have to check how attributes change in MS ODBC... perhaps
> > setting SENSITIVITY change also CURSOR_TYPE ??
>
> As I wrote in a previous mail, you should test all possible
> combinations
> of SQL Statement handle attributes with the MS ODBC MDAC
> dribver, and see
> in the SQL Server Profiler trace what sp_cursor* calls it generates.
>
> Resource in SQL Server 2005 MSDN (you probably know about this link):
>
> http://msdn2.microsoft.com/en-us/library/ms130794.aspx
>
> ...
>
> We do use the following SQLSetStmtAttr() attributes:
>
> For scrollable cursors:
>
> SQL_ATTR_CURSOR_SCROLLABLE, SQL_SCROLLABLE
> SQL_ATTR_CURSOR_SENSITIVITY, SQL_INSENSITIVE
>
> For SELECT FOR UPDATE cursors (forward only):
>
> SQL_ATTR_CONCURRENCY, SQL_CONCUR_LOCK
>

Fixed sensitivity setting some days ago.

A note about implementation. Currently we don't use sp_cursorprepare,
sp_cursorprepexec , sp_cursorexecute and sp_cursorunprepare that is we
don't use prepared cursors but we use sp_cursoropen with parameters. You
should note some penalty only cause execute plans are not reused so
often... well... I'm not exactly sure this is a big penalty cause sql
should cache plans even on normal queries... also I don't think cursors
with parameters are reused so often... considering that you don't have
to call sp_cursorunprepare if statement close you could even get some
network improves... who knows...

freddy77

[James K. Lowden]

ZIGLIO, Frediano, VF-IT wrote:
> > First, thanks a lot for looking at this cursor issue!
> >
>
> I just committed a patch to CVS... all tests you sent me are
> incorporated and working as expected!

Hooray! I think I can see the fireworks from here. Nice work, and quick!


Sebastien, please let us hear back from you as to how well the current
snapshot works for you. I feel a release coming on.

--jkl

[Sebastien FLAESCH]

Thank you Frediano for that.

Unfortunately it's Xmas time now and I will be off until the 3 Jan.

Will check then.

Thanks a lot and greetings.
Seb

James K. Lowden wrote:
> ZIGLIO, Frediano, VF-IT wrote:
>>> First, thanks a lot for looking at this cursor issue!
>>>
>> I just committed a patch to CVS... all tests you sent me are
>> incorporated and working as expected!
>
> Hooray! I think I can see the fireworks from here. Nice work, and quick!
>
>
> Sebastien, please let us hear back from you as to how well the current
> snapshot works for you. I feel a release coming on.
>
> --jkl
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>

[Sebastien FLAESCH]

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'

Attached an ODBC sample to reproduce.

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".

Note also that SQL_TYPE_TIMESTAMP params must be bound with a precision of 23 with SQL Server ODBC.
See example.

Yours,
Seb

James K. Lowden wrote:
> ZIGLIO, Frediano, VF-IT wrote:
>>> First, thanks a lot for looking at this cursor issue!
>>>
>> I just committed a patch to CVS... all tests you sent me are
>> incorporated and working as expected!
>
> Hooray! I think I can see the fireworks from here. Nice work, and quick!
>
>
> Sebastien, please let us hear back from you as to how well the current
> snapshot works for you. I feel a release coming on.
>
> --jkl
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: odbctest3.c
Type: text/x-csrc
Size: 5049 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/freetds/attachments/20080103/3ac5632d/attachment.bin

[Frediano Ziglio]

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.

> 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

[Sebastien FLAESCH]

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
>

[Frediano Ziglio]

Il giorno dom, 06/01/2008 alle 09.04 +0100, Sebastien FLAESCH ha
scritto:
> 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).
>

Profiler does its best to translate RPCs to sql statements...

> 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.
>

Don't mind, we still do not packaged any RCs... but usually after first
RCs 80-90% of efforts are spent on documentations, Makefiles and
similar!

> I will spend some hours this week to check this.
>
> Anyway, thanks for your fast answer.
>
> Seb
>

I improved genparams in order to check parameters even using cursors.

freddy77

[Sebastien FLAESCH]

Frediano,

Good news:

Just installed/compiled last snapshot and could run about 70% of my regression tests.

If you don't have ODBC tests with SQLBindParameter() using all possible data types,
I can only strongly recommend to add such test ASAP!

As a database driver interface implementer, SQL Parameter IS one of the major ODBC
features we need!

Sorry to push, I would like to contribute if I would have time.
I hope that my requests / bug reports make the project go forward.

I will check the 30% remaining and write some ODBC sample to repro if possible.

Many Thanks.
Seb

Frediano Ziglio wrote:
> Il giorno dom, 06/01/2008 alle 09.04 +0100, Sebastien FLAESCH ha
> scritto:
>> 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).
>>
>
> Profiler does its best to translate RPCs to sql statements...
>
>> 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.
>>
>
> Don't mind, we still do not packaged any RCs... but usually after first
> RCs 80-90% of efforts are spent on documentations, Makefiles and
> similar!
>
>> I will spend some hours this week to check this.
>>
>> Anyway, thanks for your fast answer.
>>
>> Seb
>>
>
> I improved genparams in order to check parameters even using cursors.
>
> freddy77
>
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>

[ZIGLIO, Frediano, VF-IT]

>
> Frediano,
>
> Good news:
>
> Just installed/compiled last snapshot and could run about 70%
> of my regression tests.
>
> If you don't have ODBC tests with SQLBindParameter() using
> all possible data types,
> I can only strongly recommend to add such test ASAP!
>

genparams!! Already present. I added just yesterday many combinations
(direct/prepare, bind before/after execute, cursors on/off).

> As a database driver interface implementer, SQL Parameter IS
> one of the major ODBC
> features we need!
>
> Sorry to push, I would like to contribute if I would have time.
> I hope that my requests / bug reports make the project go forward.
>
> I will check the 30% remaining and write some ODBC sample to
> repro if possible.
>

Does this mean that you tested 70% and is all work correctly or that you
tested 100% and 30% does not work??

> Many Thanks.
> Seb
>

We do not still support wide chars (that is ODBC 3.5) and bulk (features
not even planned).

bye
Frediano

[Sebastien FLAESCH]

ZIGLIO, Frediano, VF-IT wrote:
>> Frediano,
>>
>> Good news:
>>
>> Just installed/compiled last snapshot and could run about 70%
>> of my regression tests.
>>
>> If you don't have ODBC tests with SQLBindParameter() using
>> all possible data types,
>> I can only strongly recommend to add such test ASAP!
>>
>
> genparams!! Already present. I added just yesterday many combinations
> (direct/prepare, bind before/after execute, cursors on/off).

Perfect!

>
>> As a database driver interface implementer, SQL Parameter IS
>> one of the major ODBC
>> features we need!
>>
>> Sorry to push, I would like to contribute if I would have time.
>> I hope that my requests / bug reports make the project go forward.
>>
>> I will check the 30% remaining and write some ODBC sample to
>> repro if possible.
>>
>
> Does this mean that you tested 70% and is all work correctly or that you
> tested 100% and 30% does not work??

Sorry if I was not clear.
I ran all of my tests, 70% succeeded, while 30% failed.


>
>> Many Thanks.
>> Seb
>>
>
> We do not still support wide chars (that is ODBC 3.5) and bulk (features
> not even planned).

So far we have only U.S. customers asking for a UNIX client.
Applications are English-based, so single-byte character set is fine for now.

>
> bye
> Frediano
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>