ODBC SQLBindCol Segment Violation
camber at ais.org
Tue Jul 24 00:17:20 EDT 2001
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.
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
> 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
> gets around it. I assume a fix would involve checking for a valid res_info
> 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
> it appears to be a lifetime-scope issue. Should the bindings be kept in a
> persistent structure attached to the statement, or should the results info
> use be
> modified ?
> 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