FreeTDS Development Group

["James K. Lowden" <jklowden AT schemamania.org>]

On Thu, 15 Apr 2004, Nicolas Goy <goyman AT goyman.com> wrote:
> Fine, know it work a little bit better (a little bit:)).
> 
> The error changed, now I got:
> Message: [FreeTDS][SQL Server]Attempt to initiate a new SQL Server 
> operation with results pending.
>
> 00:00000:00018:2004/04/15 02:09:17.52 server  TDS_LANG, spid 18: command
> 
> text:
> set textsize 64512 use GAddress
> 00:00000:00018:2004/04/15 02:09:17.53 server  TDS_LANG, spid 18: command
> 
> text:
> BEGIN TRANSACTION
> 00:00000:00018:2004/04/15 02:09:17.53 server  TDS_DYNP, spid 18: command
> 
> text:
> create proc w53y006000 as SELECT 
> id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM 
> ldap_oc_mappings
> 
> as you can see, the rollback disapeard in the log.

Yes, looks good.  

> So I think the error is generated with the second sql statement.

Do you mean the "begin tran", or the "create proc" statement?  

> I think the ldap backsql work this way:
> 
> It read one result of the oc_mappings query, then it populate it with 
> attr_mappings query. But the tds driver refuse the attr_mapping query 
> because all results from oc_mappings query have not been read. Am I
> right?

That would explain what you're seeing, yes.  

<speculation> It executes w53y006000, which returns one row.  It expects
only one row.  It reads that row, then attempts an Insert statement,
knowing there are no further results.  The driver might require the
application to attempt to read past end-of-results.  That is, the driver
might not clear its "pending results" flag until it returns "no more rows"
to the application.  </speculation>

A TDSDUMP log would probably prove that right or wrong.  

> As I don't want to rewrite the ldap back-sql module (putting result into
> 
> a temp array...). I wanted to know if there was anyway to correct that.

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.  

> I browsed the archive, but I prefer to ask the question again before 
> beginning to play with the sources, as the have certainly changed.

The state of the connection (ready to accept queries or not) is maintained
in libtds.  In src/tds/query.c, for instance, you'll find lots of
statements like:

        if (tds->state == TDS_PENDING) {

If the requested function conflicts with the current state of the
connection, it returns an error, typically logging the error to the
TDSDUMP log, too.  

HTH.  

--jkl