Skip to Content.
Sympa Menu

freetds - RE: [freetds] results processing in freetds

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO Frediano" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] results processing in freetds
  • Date: Wed, 8 Oct 2003 17:02:35 +0200

>
> Hi Freddy,
>
> as usual , you manage to get across a lot of information in
> just a few sentences, unlike me!
>
> let me try and get what you've said straight in my own head....
>
> > I think we should work on curr_resinfo.. This pointer point to
> > current
> result and can be res_info or cur_dyn->res_info. token.c just
> write to curr_resinfo (or it should)...
>
> So - you're saying that token.c should just operate on
> tds->curr_resinfo , and should never set tds->curr_resinfo -
> that being responsibility of whatever calls the token.c functions...
>

Mmm... perhaps query.c should set tds->curr_resinfo. Perhaps
tds->curr_resinfo should be a TDSRESULTINFO ** and by default point to
tds->res_info ?

> > When we want to get some rows from cursors we just set
> curr_resinfo to
> > our
> cursor->res_info.
>
> And the implication is that when we wanted to get some rows
> from a normal query, we would have to set curr_resinfo to
> tds->res_info
>
> > Problem is compute. I think is a good idea to add a TDSCOMPUTEINFO
> **comp_info to TDSRESULTINFO structure and remove from TDSSOCKET.
>
> Interested to know why you think they are a problem. If I
> told you that "compute" clauses are forbidden in SQL
> statements used to open cursors, would the problem go away ?
>

Yes, for cursors. I never thought about this problem... I think dynamic
can return select with compute so we have found a new bug...

> > This was just prepared for cursors as declared in an very
> old mail...
> strangely you add curr_resinfo for this stuff..
>
> I don't understand what you're saying here.
>

We worked on a similar issues (reslts from dynamic and compute) and you
wrote the code :)

> Some other points:
>
> 1) We'll need an array or linked list of TDSCURSORINFO
> structures, as you can have more than one open cursor on the
> connection.
>

Yes, I think an API similar to dynamic one (add three fields to tds:
num_cursors, cur_cursor, cursors).

> 2) token.c (tds_process_result or other) will have to
> allocate the TDSRESULTINFO storage, as only it knows how many
> columns have been returned in the result set.

Yes, this is why cur_resinfo should be a pointer to pointer.

> How's it going to know which TDSRESULTINFO * should point
> to the allocated storage ? remember the results token from a
> cursor open looks just like an ordinary results token...
>
>
> Thanks for the help Freddy...
>
>
> Bill
>

Perhaps we should also remove tds->param_info ?? It's just another
result... Perhaps we should also add a type field (params, row, compute
row) to TDSRESULTINFO. About ret_status/has_status: these fields make
sense in both dynamic and connection; any library can ask return status
referred to a dynamic ? As a C++ programmer I'm thinking about something
like this:

class Result { ... };

class ParamResult: public Result { ... };

class RowResult: public Result { ... };

class ComputeResult: public RowResult { ... };

class tds
{
...
private:
Result *cur_resinfo;
...
};

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page