Thanks for the feedback everyone. I need to add that I tried another test. In this one, I pulled out the insert and update statement from the SP (just to confirm that what I wanted to do really would work) and the result set was returned and the fetchrow_array call did succeed and returned my recordset.
My next thought was to move the insert and update statements into their onw SP and call that SP from the original. No change; same problem. I have a workaround: I use a global temp table and moved the select into perl. It just seems to me that my original way should work. Thanks, Dave On Mar 2, Steffen Goeldner scribed: > Martin J. Evans wrote: > > > > [...] > > > > My guess (and it is a guess only) is that DBD::ADO has pulled the rows from > > the > > first result-set and knows there is nothing more (hence handle not active) > > Trace level 5 shows > > -- no fields (non-select statement?) > > i.e. DBD::ADO avoids to equip the statement handle with the > full set of attributes, which are necessary only for the fetch > loop, if the number of fields is 0. > > > because it has not done the equivalent of SQLMoreResults. > > Currently, DBD::ADO doesn't support the equivalent of > SQLMoreResults: > > > <http://msdn.microsoft.com/library/en-us/ado270/htm/mdmthnextrec.asp?frame=0> > > > Steffen >
