FreeTDS Development Group

["Thompson, Bill D (London)" <bill_d_thompson AT ml.com>]

Thanks Freddy,

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

I just finished a little experiment.

sp_prepare will return you the results metadata if you ask it to. 
we do in tds_submit_prepare, althouigh I don't think we knew what we
were doing... :)


 /* 1 param ?? why ? flags ?? */
  tds_put_byte(tds, 0);
  tds_put_byte(tds, 0);
  tds_put_byte(tds, SYBINT4);
  tds_put_int(tds, 1);

That value of 1 appears to be the only value it currently accepts ( 0 or
2 don't work),
but I know it to be a flag that means "return results metadata"

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

Obviously I'd turn it into a TDS structure... for the time being could I
do this ?

In the longer term...

The tds_submit... functions that expect to use parameters, expect a
TDSPARAMINFO pointer.

so in ct-lib and dblib RPC:

the API (ct_param or dbrpcparam) stores parameters in one type of
structure 
(CS_PARAM or DBREMOTE_PROC_PARAM These two are very similar - I cloned
ct-lib RPC from your dblib RPC...)

when we submit the RPC the dblib or ctlib code converts this structure
liist into a TDSPARAMINFO structure, using 
a function in the API library (param_info_alloc or paraminfoalloc -
again I cloned yours)
calls tds_submit... passing the TDSPARAMINFO pointer

so...

TDSPARAMINFO *pparam_info;
    ...
pparam_info = paraminfoalloc(tds, cmd->rpc->param_list);
ret = tds_submit_rpc(tds, cmd->rpc->name, pparam_info);


The submit function then uses tds_put_data_info & tds_put_data (TDS 7)
or tds_put_params (TDS 5)
to deconstruct the TDSPARAMINFO data into wire format.

I wouldn't want to change code unnecessarily, but is it possible that we
could skip the intermediate stage ?
I don't know if the tds_put_data... functions might more easily get the
information they want from the original CS_PARAM type structure ? 

Bill

-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of ZIGLIO,
Frediano, VF-IT
Sent: 20 October 2004 10:42
To: FreeTDS Development Group
Subject: RE: [freetds] Questions for Freddy


> 
> 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
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds 
--------------------------------------------------------
 
If you are not an intended recipient of this e-mail, please notify the 
sender, delete it and do not read, act upon, print, disclose, copy, retain or 
redistribute it. Click here for important additional terms relating to this 
e-mail.     http://www.ml.com/email_terms/ 
--------------------------------------------------------