FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> > 
> > Il giorno mer, 06-04-2005 alle 12:26 -0400, Lowden, James K ha
> scritto:
> > > 
> > > I discovered two things.  
> > > 
> > > 1.  There seems to be a recognized problem binding datetimes with
> > > DBD::ODBC.  It doesn't work with my odbc_rpc.pl, and I saw a few
> > > references at ActiveState on the same topic.  Should be fixable,
> > > theoretically....
> > 
> > Which problem ??
> 
> http://www.opensubscriber.com/message/perl-win32-users@listser
> v.ActiveSt
> ate.com/108164.html
> 
> I think I misunderstood the purpose of the datatype parameter to
> bind_param().  I thought it described the parameter type.  No, it
> describes the buffer to which the parameter is being bound.  Perl has
> only strings and integers, so it's a mistake to tell bind_param() that
> my Perl variable is a DATETIME.   
> 
> I get the same message from the same script on a Windows box:
> 
> $ perl odbc_rpc.pl  -D "DBI:ODBC:mpq" -U abc -P abc
> GenerationsAddParsed expann ":SQL_DATETIME:2005-04-01 16:46:00"
> :SQL_INTEGER:0
> 3 arguments found for procedure "GenerationsAddParsed"
> Binding parameter #1, the return code
> Binding parameter #2 (SQL_VARCHAR): "expann"
> Binding parameter #3 (SQL_DATETIME): "2005-04-01 16:46:00"
> Binding parameter #4 (SQL_INTEGER): "0"
> 
> Executing: "{? = call GenerationsAddParsed (?, ?, ?)}" with parameters
> 'expann', ':SQL_DATETIME:2005-04-01 16:46:00', ':SQL_INTEGER:0'
> Can't rebind placeholder 3 at odbc_rpc.pl line 85.
> 
> Only later did it dawn on my to try passing the date as a 
> string, which
> worked fine, even without altering the stored procedure.  
> 

So, not problem at all...

> > > 2.  We still have issues with error messages, even in current CVS.
> > > Consider this stored procedure:
> > > 
> > > create proc t 
> > > as begin
> > >   select 'Here is the first row' as FirstResult
> > >        raiserror( 'This is an example error message.', 16, 1)
> > >   select 'Here is the last row' as LastResult
> > > end 
> > > 
> > > We should see one message and two results (one row each). 
>  But here
> is
> > > today's surprise answer:
> > > 
> > > $  ./samples/odbc_rpc.pl  -Ddbi:ODBC:mpq -U$U -P$P  t
> > > Binding parameter #1, the return code
> > > 
> > > Executing: "{? = call t }" with parameters ''
> > > execute returned: '-1'
> > > Result #1:
> > > [FirstResult]
> > > 'Here is the first row'
> > > DBD::ODBC::st fetchrow failed: [unixODBC][FreeTDS][SQL Server]This
> is an
> > > example error message. (SQL-)(DBD: st_fetch/SQLMoreResults err=-1)
> at
> > > ./samples/odbc_rpc.pl line 94.
> > > 'Here is the first row'
> > > 'Here is the last row'
> > 
> > :( 
> > A complex mix for error and resultsets...
> > James, post odbc and freetds logs.
> 
> Attached (I hope).  
> 
> I also wrote dblib_rpc.pl, which I'll commit soon too.  It 
> demonstrates
> that the db-lib rpc code handles server messages just fine.  
> And I'd say
> -- can you guess? -- the API is easier to use.  Of course, it can only
> call stored procedures; it's not as flexible as ODBC's 
> prepare/exeucute.
> 

I would have prefer DM log but I manages to update raiserror.c test.
I discovered some problems:
- FreeTDS accept SQLGetData calls before SQLFetch (returning NULL)...
not that fine
- MS SQLMoreResults return correctly SQL_ERROR/SQL_SUCCESS_WITH_INFO
however if you get data with SQLGetData it seems to eat error
(SQLMoreResults returns SQL_SUCCESS, perhaps it returns error on
SQLFetch/SQL_NO_DATA), I think that for this reason Perl success on
windows but is mainly broken, if it detect that there are no rows
(calling SQLFetch) it should assume the SQLMoreResults change recordset
even returning SQL_ERROR...
- FreeTDS seems to return a false SQL_SUCCESS after last rows

freddy77