Skip to Content.
Sympa Menu

freetds - Re: [ODBC] SQLBindParameter

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Brian Bruns" <camber AT ais.org>
  • To: freetds
  • Subject: Re: [ODBC] SQLBindParameter
  • Date: Mon, 28 Feb 2000 15:27:42


Ken,

The TDS_PARAM_INFO structure is designed to handle 'output' stored
procedure parameters. So it may not be what you are looking for. The
patch looks good though. I'm not sure how that one slipped by, the
tds_free_param_results() function seems to treat it correctly...

ctlib also supports placeholder values, however I've never implemented
them. You may want to check sybooks.sybase.com under the CT-Library manual
for details on Sybases implementation. (ct_dynamic() and friends). There
is protocol level support for it, however I doubt that MS SQL does it the
same way since it is a post-4.2 addition. I've never traced a prepared
statement to see way it looked like. BTW, DBD::Sybase would benefit from
placeholders as well.

Just guessing, but the query is sent to the server with the TDS_LANG_TOKEN,
a size and 3 more bytes. I imagine these probably flag prepared
statements, but that is just conjecture on my part...I'd need to do a trace
of the traffic to know for certain. Again though, this would not work
under TDS 4.2 and probably works differently under TDS 7.0 (if at all).
So, a safe bet would probably be to implement it client side first then
optionally do protocol level implementations for TDS 5.0/7.0.

Brian

On 02/28/00, "Ken Seymour <kenaseymour AT yahoo.com>" wrote:
> Brian,
>
> This weekend, I decided to test the ODBC driver with
> parameterized select statements.
>
> To do this I used the pubs2 example database and did
> the following:
>
> select title from titles
> where total_sales = ?
>
> This requires calling, in order:
>
> SQLPrepare
> SQLBindParameter
> SQLExecute
>
> I debugged into SQLBindParameter and found that the
> param_info structure was not allocated. So I added
> a call to tds_alloc_param_result (in tds/mem.c).
> This caused a SEGV and upon further inspection,
> this routine looks like it is missing a malloc.
>
> It was after I added this and got SQLBindParameter
> working that I discovered that SQLExecute does not
> make use of the parameters and Sybase attempts to
> give me a message of 'syntax error near ?' or
> something like that.
>
> To my knowledge, there are not parameter routines in
> tds (or dblib for that matter). So I suppose I will
> have to implement it on the client side.
> Since I suspect that SQLPrepare can be called once
> and SQLExecute several times with different parameter
> values (in the same bound variables), I will need
> to keep the original SQL text, substitute the question
> marks for the stored parameter values, and pass along
> the translated SQL text to TDS.
>
> I am getting ready to check in changes to odbc/odbc.c
> and tds/mem.c. I wanted to check in with you first
> since this is outside the odbc tree.
>
> I will add
>
> param_info->columns[0] = (TDSCOLINFO*)
> malloc (sizeof (TDSCOLINFO));
>
> before the second memset in if (!oldparam) and add
>
>
> param_info->columns[param_info->num_cols-1] =
> (TDSCOLINFO*) malloc (sizeof (TDSCOLINFO));
>
> before the second memset in the else block.
>
> What do you think?
>
> __________________________________________________
> Do You Yahoo!?
> Talk to your friends online with Yahoo! Messenger.
> http://im.yahoo.com




Archive powered by MHonArc 2.6.24.

Top of Page