FreeTDS Development Group

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

Freddy,

I ran into what (I think) is a similar issue with compute data.

Briefly, AIUI, the problem is this:

we submit a command to the server, e.g."select * from table" and we get the
following back:

1) a set of "result" information, describing the output columns
2) one or more data rows 

The code currently stores the result information in tds->res_info, and
assumes that the following data can be decribed by that structure.

With compute data, we might submit a command like this :

select * from table
order by col3
compute sum(col1) by col3
compute avg(col2)

This server will, send us back:

1) a set of "result" information, describing the output columns of the
regular data
2) a set of "result information describing the output columns from the 1st
compute clause (compute sum(col1) by col3)
3) a set of "result information describing the output columns from the 2nd
compute clause (compute avg(col2))
4) rows of regular data, interspersed with rows of compute data, whereever
the "control breaks" occur in the data.

In order to handle this, I needed to store multiple sets of result data, and
have a method of relating the data rows to the correct result data.

I have achieved this by keeping tds->res_info for "regular" data and also
maintaining an array of res_info type structures for the compute data
results

I saw the params/dyn code, but left it alone as I knew you were working on
it....

I don't understand the functionality behind the "params" code, so I have
some questions for you :

What command is submitted to the server, which results in this data being
returned ?
Can that command also return "regular" row data ?

If the command can only return one set of "result" data, namely the "param"
result data, then I see no reason why you should not (re)use tds->res_info
to store it.

It's only if the logical command can return more than one set of result data
, that a different structure should be necessary to store it.

Hope you understand this, and it helps a little.

BTW, my work on compute data should be available later this week....


Bill

> -----Original Message-----
> From: Frediano Ziglio [SMTP:freddyz77 AT tin.it]
> Sent: Sunday, October 13, 2002 9:05 PM
> To:   TDS Development Group
> Subject:      [freetds] varaddr parameter and column
> 
> I started time ago coding dynamic query for use it on odbc.
> But I stopped coding for problem with parameters.
> 
> Parameters seem similar to column info. They have a type, can be binded,
> can contain same data (even blob) but work in different direction and
> this give some problem.
> 
> Column are readed from wire to row buffer so client api can call tds to
> retrieve values. Params are mostly written to wire so library should
> write into buffer and then passed to tds that write on wire. But
> information are stored in very differently mode. 
> 
> For column into
> 
> TDSSOCKET -> TDSRESULTINFO* res_info -> current_row and columns
> 
> For parameters
> 
> TDSSOCKET -> TDSPARAMINFO *param_info
> but also (why?)
> TDSSOCKET -> dyns [cur_dyn_elem] -> TDSINPUTPARAM **params
> 
> But they contain very different information...
> Why use params from dynamic instead of using param_info ?? Why they are
> different ?
> I know that every statement in ODBC can have is bindings but this is
> true for result...
> 
> Simply I don't understand the right method for writing parameters into
> tds and for read them...
> 
> 
> Next part of mail is a big future change I intent to implement (in some
> way, it can cause many problems, so is only design not coding for now)
> 
> It seem that varaddr is not very used in tds. It seem a repository for
> client information. Old stuff still there? Perhaps tds should support
> bindings? Many types are equal (byte speaking) from client to tdslib but
> someone (the bastard numeric) are different. IMHO a method to support
> direct binding in tds (writing directory to application) is to use
> callback specified client routines (or null if type is the same). For
> example if you want to write a numeric we just call a function
> (registered in TDSCOLINFO) like writedata(void* data, int length) tds
> call it with (&my_numeric,0), (0 mean fixed size, <0 for negative) for
> writing numeric and lib translate numeric and write directly to
> application. For blob/text tds can call function more time (just like a
> file). Perhaps some other information (TDSSOCKET, TDSCOLINFO) are
> useful.
> 
> freddy77
> 
> 
> 
> ---
> You are currently subscribed to freetds as: [thompbil AT exchange.uk.ml.com]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')