ODBC SQLBindCol Segment Violation

Brian Bruns camber at ais.org
Tue Jul 24 00:17:20 EDT 2001



Hrmph,

We used to do this correctly...in fact there is still a pointer to the
bind_head in the statement structure (_sql_bind_info if you check
tdsodbc.h), the idea was that the bindings would be stored there until
there was a result set and then transfered to the proper place.

Somewhere along the line somebody "streamlined" the code, and I don't
recall doing it myself.  I don't have time right now, but I'll pile it on
the TODO list.

Cheers,

Brian


On Tue, 24 Jul 2001, Varley, David(CBorn at Alcoa) wrote:

> 
> I don't know how many of you are using ODBC, but here's a problem I've just
> tracked down.
> 
> SQLBindCol should be callable on a statement before any results are
> returned.
> This works on Windows, but at present FreeTDS doesn't allocate the res_info
> for column bindings until after result set is returned, and you get a
> segment violation. Moving the column binding after the result set is
> returned
> gets around it. I assume a fix would involve checking for a valid res_info
> in
> SQLBindCol, and creating it if not found, but I'm not sure enough about the
> overall structure, how thing hang together and why. I think the res_info
> may be cleared when the results come in anyway, which would make this
> pointless,
> it appears to be a lifetime-scope issue. Should the bindings be kept in a
> separate
> persistent structure attached to the statement, or should the results info
> use be
> modified ?
> 
> Cheers,
> 
> David
>  
>  
> 
> Alcoa World Alumina Australia is a trading name of Alcoa of Australia Limited,  ACN 004 879 298
> 
> 
> ---
> You are currently subscribed to freetds as: [camber at ais.org]
> To unsubscribe, forward this message to $subst('Email.Unsub')
> 




More information about the FreeTDS mailing list