FreeTDS Development Group

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

> 
> > 
> > 
> >>So I think the error is generated with the second sql statement.
> > 
> > 
> > Do you mean the "begin tran", or the "create proc" statement?  
> 
> I mean the create proc (select from ldap_attr_mappings), but 
> really not 
> sure.
> 
> 
> > 
> > A TDSDUMP log would probably prove that right or wrong.  
> > 
> 
> You will find it at the end.
> 
> > 
> > My hypothesis wouldn't be hard to test.  If it turns out to 
> be accurate, I
> > think that would constitute a bug, because I doubt the ODBC standard
> > requires an application to try to read a nonexistent row 
> before issuing
> > the next query.  
> > 
> The content of the table can be found at the end too.
> 
> 
> 
... skipped ...

>From log I can say that your application read first row but not the
second one, so you have the error... It would be useful a ODBC trace. My
/etc/odbcinst.ini has these rows to enable trace (unixODBC)

[ODBC]
Trace           = Yes
TraceFile       = /tmp/sql.log
ForceTrace      = No
Pooling         = No

freddy77