Skip to Content.
Sympa Menu

freetds - Re: [freetds] Does SQLBindParameter work with SQLExecDirect

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddyz77 AT tin.it>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Does SQLBindParameter work with SQLExecDirect
  • Date: Thu, 07 Aug 2003 21:09:33 -0000

Il gio, 2003-08-07 alle 22:45, David Fraser ha scritto:
> Thanks for the info Freddy. It's as I suspected. The Prepare/Execute
> method will work fine for me just now.
>
> However...
>
> For what it's worth, wisely or otherwise, I checked out the
> latest 0.62-devel code from CVS to try it out, and with this code
> I find that SQLBindParameter NEVER works (and no diagnostic
> is forthcoming) - whereas it worked with 0.61 with Prepare/Execute.
>
> Perhaps you know about this already and its my problem for taking
> code under-development.
>
> I should say I'm using it with iODBC (3.0.6). (The iODBC version
> was constant throughout).
> I did some investigation and have the following observations (based on
> a little bit of gdb'ing and gross assumptions about the code - I stand by
> to be corrected - but here's my take...)
>
> 1) In 0.61 there was no SQLBindParam in odbc.c - just
> SQLBindParameter.
> 2) In iODBC's prepare.c when SQLBindParameter is invoked it
> actually invokes the driver's (new) SQLBindParam function.
> Although - if there had been no SQLBindParam driver function
> then it would have invoked the driver's SQLBindParameter
> instead. This last was the behaviour with 0.61 - but not any
> more.
> 3) Now the driver's SQLBindParam function is a simple wrapper
> - it invokes SQLBindParameter. Now I suspect it wants to
> invoke the driver's SQLBindParameter, but it actually
> invokes iODBC's SQLBindParameter - which takes us back
> to step 2 - i.e. there is no way the driver's SQLBindParameter
> will get called. (as far as I can see). Anyway, here's the gdb
> stack dump to back up my suspicion. #0 and #2 are the same
> function.
>
> >#0 SQLBindParameter (hstmt=0x806a130, ipar=1, fParamType=1, fCType=-15,
> > fSqlType=4, cbColDef=0, ibScale=0, rgbValue=0xbfffe038, cbValueMax=0,
> > pcbValue=0xbfffe03c) at prepare.c:449
> >#1 0x401535ae in SQLBindParam (hstmt=0x806a130, ipar=1, fCType=-15,
> > fSqlType=4, cbColDef=0, ibScale=0, rgbValue=0xbfffe038,
> > pcbValue=0xbfffe03c) at odbc.c:785
> >#2 0x40054706 in SQLBindParameter (hstmt=0x804dd88, ipar=1, fParamType=1,
> > fCType=-15, fSqlType=4, cbColDef=0, ibScale=0, rgbValue=0xbfffe038,
> > cbValueMax=0, pcbValue=0xbfffe03c) at prepare.c:428
> >#3 0x08049b16 in TestRawODBCPreparedQuery() () at dbtest.cpp:272
> >#4 0x0804a985 in main () at dbtest.cpp:489
>
>
> It strikes me that SQLBindParam needs re-written to call something
> that doesn't look like an iODBC function - perhaps by factoring out
> the contents of SQLBindParameter into a common function with
> a local name. Just a thought - based on little knowledge I admit :-)
>
> BTW - perhaps it could be argued that the iODBC code is wrong.
> I don't know. I tried ifdef'ing out the call to SQLBindParam from
> iODBC's SQLBindParameter so that
> it does call the driver's SQLBindParameter and it works a treat
> including with SQLExecDirect. So that workaround works (which
> fixes my original problem!)
> I'll leave it to you to figure out whether iODBC or FreeTDS is right
> or wrong on this new issue.
>
> Hope this half-baked analysis helps,
>
> David
>

Hi David!

You are right in all!!
Fixed in CVS

freddy77






Archive powered by MHonArc 2.6.24.

Top of Page