ADO Objects

[John Hicks]

Dan,
Sorry about the last post. How would I know that the tab/enter key would
send the message?
I am working on a really stubborn problem. We are using asynchonous ADO
recordset retrieval. There has been a mysterious bug where occaissionally
(less than 1% of the time), the List_Progress/List_Complete events wouldn't
fire. When this happens it is REALLY hard to build a work around (we even
tried a timer).
Anyway, this led us to try ADO 2.5. Now we have a much worse bug. On
certain machines (all Win98 so far, the rest are NT), the last list progress
event doesn't fire. Suppose I have 70 records to retrieve, and a Fetch Batch
size of 10: The system will fire the Fetch_Progess only 6 times, then fire
Fetch_Complete. Needless to say this is a problem, and harder to fix since
it happens only on Win98 (so far) machines.
I have a theory; please tell me if I'm nuts. When the Fetch_Complete
event fires, we destroy the ADO objects (connection, recordset). Since the
data retrieval is happening on another thread, perhaps we are not finished
processing an earlier Fetch_Progress message. When the object gets destroyed,
we never get it.
I don't know a great deal about marshalling across threads, so I don't
know if this is a reasonable theory. DoEvents in the Fetch_complete event
didn't help.

Any help is appreciated.

Thanks

[Dan Appleman]

I'm not really that familiar with asynchronous ADO recordset retreival, but I'm
not sure I see the problem.
You are getting the FetchComplete event, so you know when all the data has been
retrieved. Why do you care that not every FetchProgress event arrived?

In fact, looking at the documentation, I don't see anything to suggest any
commitment on the part of ADO to call FetchProgress for any particular number of
records (or at all). Nor is there a commitment that there will be a final one
after all records are retrieved (that's what FetchComplete is for).

Now, again, this is not my area of expertise, but that's my quick read of the
situation.

Dan


John Hicks wrote:

> Dan,
> Sorry about the last post. How would I know that the tab/enter key would
> send the message?
> I am working on a really stubborn problem. We are using asynchonous ADO
> recordset retrieval. There has been a mysterious bug where occaissionally
> (less than 1% of the time), the List_Progress/List_Complete events wouldn't
> fire. When this happens it is REALLY hard to build a work around (we even
> tried a timer).
> Anyway, this led us to try ADO 2.5. Now we have a much worse bug. On
> certain machines (all Win98 so far, the rest are NT), the last list progress
> event doesn't fire. Suppose I have 70 records to retrieve, and a Fetch Batch
> size of 10: The system will fire the Fetch_Progess only 6 times, then fire
> Fetch_Complete. Needless to say this is a problem, and harder to fix since
> it happens only on Win98 (so far) machines.
> I have a theory; please tell me if I'm nuts. When the Fetch_Complete
> event fires, we destroy the ADO objects (connection, recordset). Since the
> data retrieval is happening on another thread, perhaps we are not finished
> processing an earlier Fetch_Progress message. When the object gets destroyed,
> we never get it.
> I don't know a great deal about marshalling across threads, so I don't
> know if this is a reasonable theory. DoEvents in the Fetch_complete event
> didn't help.
>
> Any help is appreciated.
>
> Thanks