Re: Does SQLBindParameter work with SQLExecDirect

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