FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.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 ?
> 

I think this is 0.64 (or whatever) stuff... Does CVS work flawlessy on
Solaris? It seems to be that these platforms works correctly:
- Linux
- FreeBSD
- HP-UX

> 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
> 

No, don't forget that all libraries (dblib/ctlib and ODBC) have slighly
different structure to store data, we can't support ll types in
libTDS... In 0.53 (or 0.60?) we removed all library conversions stuff
from libTDS and at the same time we add an extra stage too. From TODO

. limit copy of data (now wire -> tds -> temp -> client)
  use a method like zero-copy
  In token.c getting row should write data even to client
  (callback, new user types, see ctlib conversion functions)
  In query.c writing data do the same (use additional column fields?)

For parameters it's client -> libTDS -> wire (as you can note it's even
better...). I know that client -> wire would be better however you have
to consider:
- bind type different (use defined, CS_VARBINARY and so on)
- bindlen different (CS_UNUSED, CS_NULLTERM)
- null indicator different (different values and even different
sizes...)
libTDS should send request (cause it should handle all the wire
communication) however higher library should convert the data and use
bindings. This it's the reason why there are fields in TDSCOLUMN (a
libTDS structure) not used by libTDS...

A solution can be to translate library view into libTDS view just before
sending data 
- read null indicators and binding lengths and fill libTDS fields in a
uniform new way
- convert data as needed
For example use a lenght of -1 for null, column_size for fixed types,
bytes length for (var)char/binary (any suggestion for numeric?). This
information can be stored in column_cur_size and, for instance,
column_offset can be set to 0 to indicate that column_varaddr it's used
to store binded data (which have to be coded in libTDS format).

freddy77