On 23-Feb-2004 Jeff Urlwin wrote:
<excessively snipped>
Not that I am following this DBI discussion here closely but I remember one more
issue with DBD::ODBC and MS SQL Server.
> 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:
a procedure returning output parameters
> 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
output parameters returned on the last call to SQLMoreResults.
> 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
e.g. SQL = {? = call fred(arguments) }
the ? output parameter is not available until the last SQLMoreResults returns
SQL_NO_MORE_DATA.
Don't know if this makes any difference to the discussion - just thought I'd
mention it.
Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development
