I also use Set NoCount On at the beginning of all my Procs, and do not
ever turn it off again...... Have had no propblems using that technique
> That is interesting. I knew that ADO might *on "rows affected"
> _PROC) messages, but I didn't know that there is a difference if the
> DONE_IN_PROC is returned by a SELECT or by UPD/INS/DEL. Makes sense when
> think about it. UPD doesn't return column meta-data, so ADO doesn't
> understand a row-count without column-metadata. (Hey ADO developers at MS,
> do you read this? :-).
> As Kurt suggested, just SET NOCOUNT ON at the beginning of your proc code
> (or the batch, if it isn't a proc). AFAIK, you don't have to turn it on
> before a SELECT (I'm fairly certain of that).
> There's a trace flag to disable DONE_IN_PROC globally, at the server
> Search for "trace flag".
> Tibor Karaszi
> MCDBA, MCSE, MCSD, MCT, SQL Server MVP
> Cornerstone Sweden AB
> Please reply to the newsgroup only, not by email.
> > Using SQL 7.0, ADO 2.1 from VB
> > Guys, this is driving me bonkers. I can use ADO to access multiple
> > recordsets from SP. Works like a charm UNLESS I put anything other than
> > SELECT statements in my SP. One INSERT statement kills the whole
> > group - it will not open. rs.NextRecordset can't even be used.
> > I suspect SQLOLEDB or ADO doesn't know what to do when SQL returns the
> > results from such a query like:
> > "2751 row(s) affected."
> > Is there any way to tell SQL server or the SP not to tell the driver
> > anything -- or is there something in ADO I'm missing that I need to
> > handle -- parameter-wise maybe?? I'm not trying to return any values,
> > the multiple SELECT result sets.
> > Really at wit's end here.