>
>
> >>
> >> Also, I'd like DBI v2 to have an official method to 'reset' a
> >> statement handle back to its virgin state so that an official
> >> more_results() method can be added.
> >
> > That would be good -- and it would be good to consistently
> handle it
> > -- as best as possible.
> >
> >
> > > I think DBD::ODBC and DBD::Sybase have this already. DBD::Pg
> > > may do. DBD::mysql is going to need it etc etc. So the DBI
> > > needs to support it so it's done consistently and to make
> > > life easier for future driver authors.
> >
> > Yes!
> >
> > >
> > > I'd appreciate it if all driver authors who have written such
> > > code to send
> > > (just) me a copy of the function so I can get an idea what
> > > you're all doing.
>
> DBD::Teradata has a similar mechanism, but its
> an $sth attribute, rather than a method call, ie,
>
> while ($sth->{tdat_more_results}) {
> while ($row = $sth->fetchrow_arrayref) {
> #do some stuff
> }
> }
That's the same as DBD::ODBC (odbc_more_results).
>
> In addition, the $sth has tdat_stmt_num and tdat_stmt_info
> attributes which provide the current statement number and a
> hashref of statement information (activity type, activity
> count, the fields in the output $row which are filled by the
> current statement, etc.) See
> http://www.presicient.com/tdatdbd/#mstmts and
>
http://www.presicient.com/tdatdbd/#stinfo for details.
> Which raises another issue: at present DBD::Teradata allocates a $row
array with a size equal to the sum of the number of > columns for each
statement. I've tried adjusting the NUM_OF_FIELDS on the fly to represent
just the number of fields for > > the current statement, but DBI carps. And
of course, it presents some issues for providing statement metadata. Any
chance > the more_results() work will provide a more elegant solution ?
Actually, check out DBD::ODBC. If you need help, let me know, but I did do
some hacks that I got from DBD:Sybase which clears out NUM_OF_FIELDS, etc...
Jeff
