FreeTDS Development Group

[Sebastien FLAESCH <sf AT 4js.com>]

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