>
>
> [CC'd to dbi-dev as it's of general interest. I trust that's okay.]
Yep.
[snip]
> > However, I have some issues with that -- and they may only
> be mine.
> > The cacheing is not working on this and due to the way I've
> > implemented DBD::ODBC and SQLMoreResults(). My first call to my
> > dbd_describe() fails miserably in my test case. But the
> second time
> > through, it doesn't because I've called SQLMoreResults() and
> > dbd_describe acts as if there is no result set (num_fields
> == 0). So,
> > the second time around, I get an empty array. I would have to
> > re-design the code a bit to handle that and am a bit hesitant to do
> > that since I worked the behavior through at length a while
> ago to 'do
> > what makes sense' for at least some conditions. This is one of the
> > edge cases.
> >
> > Is it OK to move forward with an empty array, or would you strongly
> > prefer the null reference?
>
> undef.
Ok.
>
> 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.
That's a little harder for me, but I'll try to summarize what I did and try
to remember the reasons why. It got nasty there for a while, especially
with SQL*Server stored procs (just look at all the 45_xx releases! I do
remember, at first, it was a simple: if you called for more results, I'd
check then. But there were a few nasty instances where, inside a procedure,
you'd have:
update
select a, b, c
update
update
select d, e, f
SQL*Server returned, respectively:
empty result set
a, b, c
empty
empty
d, e, f
What DBD::ODBC does now is that the end-user will only see (I think! It's
been a while!):
a, b, c
d, e, f
This is to keep the loops simpler and, I think, doing a fetchrow_array on an
update result set triggered (Raise|Print)Error.
So, you can now:
$sth->execute;
do {
while (@row = $sth->fetchrow_array) {
}
} while ($sth->{odbc_more_results};
In retrospect, it would be simpler for a *lot* of things if the call to
odbc_more_results triggered the code instead of automagically looking for
result sets that return results...but the other way around caused headaches
for the application developers. Note that it may be a DBD::ODBC bug to
Raise/Print error when fetching a row against an update statement which
triggered this whole (derailed?) train of thinking...
It would be good if DBI defined the behaviour for this -- and sooner rather
than later...IMHO, especially if others will need it.
Regards,
Jeff
