>>
>> 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
}
}
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 ?
Dean Arnold
Presicient Corp.
www.presicient.com
