Skip to Content.
Sympa Menu

freetds - RE: [freetds] Questions for Freddy

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Questions for Freddy
  • Date: Wed, 20 Oct 2004 11:41:47 +0200

>
> Hi Freddy,
>
> I'm getting somewhere with the dynamic sql with placeholders in
> ct-library.
> I have some questions, I hope you can help.
>
> Here's how the ct-library API works for dynamic queries
>
> You first prepare the statement. In TDS 5.0 there is a TDS message for
> PREPARE.
> You can just send the basic SQL string with palceholders, e.g.
> "select * from table where key = ?'
>
> After you have issued the PREPARE, you can call an API to describe for
> you the input parameters and the output result set.
> This is possible, because in TDS 5.0, Sybase returns you a
> TDS_PARAMFMT
> message and a TDS_RESULT message from the PREPARE directive.
>
> 1) What will sp_prepare return you ? I don't suppose it is going to
> perform the same service as TDS 5.0....
>

It just return the handle of prepared statement, it do not return
parameter informations, instead it wants parameter information.

> After prepare, you can set up the parameters for the call
> using ct_param
> or ct_setparam, just like for an RPC call.
> You would call these functions once for each parameter.
>
> currently, ct_param and ct_setparam store the parameter
> information in a
> CS_PARAM structure linked list.
> There's a root pointer to one of these in the RPC structure.
> I inherited these structures from your work on db-library RPC calls.
> The parameters can be stored by value (ct_param) or reference
> (ct_setparam) and the CS_PARAM structure accomodates both types.
>
> The next problem is this incompatibility.
> in the TDSDYNAMIC structure we have a structure for storing
> parameters,
> but it is a TDSPARAMINFO structure.
> I guess I'd like to have a CS_PARAM structure in there as well.
>

CS_PARAM it's a ctlib structure, TDSDYNAMIC it's a libTDS structure, so
it's wrong to have CS_PARAM in TDSDYNAMIC.

> 2) how are parameters passed in ODBC ? are they given one by one as in
> ct-lib ? does the method support passing parameters by reference ?
> If so, have you some code in ODBC for taking parameters
> and storing
> them in the TDSPARAMINFO structure ?
>

ODBC pack all parameters in TDSPARAMINFO. It's not that good but works.
If you remember I proposed to change some row/param stuff, however it's
a very deep change so it's still a TODO. I'd like to support getting
parameters from library. This however require that libTDS can translate
from library structure (like ODBC numeric or even user defined for
ctlib) directly to TDS wire format... The only implementation I see it's
using callbacks... In ODBC for example
first we translate DATETIME/NUMERIC to libTDS format then we call
libTDS to handle data. Another ODBC option it's start sending data and
than pass it chunk by chunk. For example you can prepare a "insert into
data(text_column) values(?)" call execute and that fill text column
using SQLPutData. This would require to stop libTDS in the middle of a
RPC call !!!
Well... this it's surely a future feature :)

> I will have some more questions I am sure....
>
> Bill

Ask, ask.

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page