Re: OLE error 80040200 when assigning events of a TCustomADODatasetpointingto a multi-select stored proc

From: Fabio Dell'Aria (thesun_at_inwind.it)
Date: 05/06/04 

Date: 6 May 2004 02:02:00 -0700

"Viatcheslav V. Vassiliev" <support@oledbdirect.com> wrote in message news:<40993546$1@newsgroups.borland.com>...
> > So, are you saying calling EnableEvents after open is a valid approach?
> It is working approach. Not the best (best is correcting OpenCursor
> procedure) but working.
>
> > Procedure example
> Procedure should have some statements and first one should return closed
> recordset (query that does not return records). For example:
>
> CREATE PROCEDURE test_proc AS
> CREATE TABLE proc_test (Col1 Int)
> INSERT INTO proc_test VALUES(1)
> SELECT * FROM proc_test
>
> P.S. When you call .NextRecordset check that it is not closed before
> assigning it to TADODataSet.Recordset - the code similar to
>
> while Recordset.State = adStateClosed do
> try
> FRecordsetObject := Recordset.NextRecordset(VarRecsAffected);
> if Recordset = nil then Abort;
> except
> DatabaseError(SNoResultSet, Self);
> end;
>
> //------------------------------------------
> Regards,
> Vassiliev V. V.
> http://www.managed-vcl.com - using .Net objects in Delphi for Win32 +
> ADO.Net
> http://www.oledbdirect.com - The fastest way to access MS SQL Server,
> MS Jet (Access) and Interbase (through OLEDB)
>
>
> "Oliver Giesen" <NO.ogware.SPAM@gmx.ALLOWED.net.INVALID> ???????/???????? ?
> ???????? ?????????: news:409907e7@newsgroups.borland.com...
> > Viatcheslav V. Vassiliev wrote:
> >
> > > No, all properties should be set on initial recordset before Open().
> Next
> > > recordsets will inherit properties (such as cursor location).
> >
> > But apparently not the (contents of the) ConnectionPointContainer?
> > Otherwise this wouldn't have been a problem in the first place, would it?
> >
> >
> > > There should be no memory leaks because TADODataSet is not reference
> > > counted - recordset should hold pointer to TADODataSet that is set in
> > > Advise() - this interface (IUnknown(TADODataSet)) should be released in
> > > Unadvise() call.
> >
> > So, are you saying calling EnableEvents after open is a valid approach?
> >
> >
> > I'm intending to report this to QC, but I'm still having trouble
> > producing a simplest case test scenario especially concerning the
> > characteristics of the stored procedure that is causing the multiple
> > recordsets being returned (with the first one being closed). Simply
> > having two select statements as in the example below does contrary to my
> > expectations not suffice to produce this symptom:
> >
> > declare @Temp int
> > select @Temp = 0
> > select * from wherever
> >
> > The procedure that alerted me to the problem is by far the most complex
> > we ever wrote and it is pretty hard to tell, what exactly might be
> > causing this. It uses temp tables and unions as well... any ideas?
> >
> > Cheers,
> >
> > Oliver

You can try EurekaLog (www.eurekalog.com).

EurekaLog is an add-in tool that gives to your application (GUI,
Console, Web, etc.) the ability to catch every exception (even those
raised by memory leaks) and every infinite-loops/deadlock bugs,
generating a detailed log of call stack (with unit, class, method and
line #), showing and sending it back to you via email. 

--
Best regards...
Fabio Dell'Aria.