[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freetds
Subject:    [freetds] Re: More ODBC driver documentation desired
From:       Brian Bruns <camber () ais ! org>
Date:       2002-02-06 5:24:10
[Download RAW message or body]


Ok, I've hacked the code enough to support input parameters in the sql 
(it's not pretty, but I'll be cleaning it up from here).  The problem is 
that OpenLDAP is doing something like this:

    stmt1 = SQLPrepare(...);
    stmt2 = SQLPrepare(...);
    SQLExecute(stmt1);
    while (SQLFetch(stmt1)) {
       SQLExecute(stmt2);
    }

which completely bombs because a query is already in progress on that 
connection.  Now my question for you ODBC experts, is this something that 
just happens to work in other drivers, or is this mandated to work by the
ODBC spec? I'm suspecting this is supposed to work and I'm going to need 
to be able to grab a new connection as needed.

Brian

On Tue, 5 Feb 2002, Brian Bruns wrote:

> Ok, I've finally bootstrapped myself up with a working OpenLDAP 
> installation with unixODBC 2.2.0 and all the rest.  Created a set of 
> sybase sql files while I was at it.  Have to contribute them...
> 
> It's an old bug. ODBC allows one to bind (either SQLBindParameter or 
> SQLBindCol) between when a query is prepared and when it is executed.
> 
> Since we don't actually know anything about the query until execution time 
> we can't assign the proper values into the right structures (they don't 
> exist).  What use to happen is a temporary linked list _sql_bind_info was 
> kept and then applied during SQLExecute(). Somewhere along the line this 
> got removed and now it's bitten us.
> 
> I'll see what I can do to put it back in place.
> 
> Brian
> 
> On Tue, 5 Feb 2002, Dan Melomedman wrote:
> 
> > Peter Harvey writes: 
> > 
> > > I have taken a closer look at the problem. It is starting to look like a   
> > >  FreeTDS ODBC driver problem. 
> > > 
> > > In the FreeTDS ODBC driver I changed this... 
> > > 
> > >   _set_func_exists(pfExists,SQL_API_SQLBINDPARAM); 
> > > 
> > > to this...
> > 
> > This probably won't help you much, but so far I've tried unixODBC version 
> > 2.0.0 and 2.0.9 with 0.53 release, and the server seg faults in that same 
> > place for both. With the -current downloaded today, all three versions seg. 
> > fault. I also tried iodbc - seg. fault in the same place. 
> > 


---
You are currently subscribed to freetds as: [freetds@progressive-comp.com]
To unsubscribe, forward this message to leave-freetds-113879Q@franklin.oit.unc.edu
[prev in list] [next in list] [prev in thread] [next in thread]