VB6 to C# .NET non-blocking ADO approach

  • Thread starter Thread starter Rene
  • Start date Start date
R

Rene

Hi,

In my VB6 application I'm using a class/object that is using full-async ADO.

I can start multiple queries, the class stores the ADODB.Recordset object in
an array and waits for the QueryComplete event. This will set the result and
flag 'the query is finished' in the array.

In my WaitForResult() method I wait till the flag 'query is finished' is set
and return to the caller. While waiting I'm calling DoEvents and delay
function to prevent blasting the CPU so my VB6 application keeps responding
(pseudo code at the end of this posting).

In .NET I want to create about the same object as in VB and prevent
application to hang during long running queries. From a MDI application I
want to be able to run multiple queries at the same time.

One advantage is that in C# I'm be able to use threads, I'm using them in
C++ project too, but I'm not sure this is the best way to go. Using events
is IMO not a good approach because I should break-up my code when retrieving
some data.

When using threads I can use a semaphores or event handlers, but while
waiting them my application will block. Seems te be no other way then
calling a messagepump while waiting, is there a preffered way to do this in
..NET?

Another idea is split up the code for queries that almost return immediately
(run in same thread/blocking) and long running queries (creates another
thread/non-blocking).

What is a good approach for writing such class around ADO.NET? And what is a
good approach to prevent desktop applications from blocking?

TIA,

Rene



In pseudo code:

If class.QuerySomething ("Select bla bla" ) Then
' Query successful
Else
' Report error class.GetLastErrMSg()

class.QuerySomething ( Query, Parameters )
Declare rs as new ADODB.Recordset
Open query

QuerySomething = WaitForResult (rs)


class.WaitForResult ( rs )
index = StoreInArray (rs)

While not QueryComplete (index)
DoEvents
' Some other stuff
Wend

WaitForResult = GetResults (index)
FreeObjectInArray (index)


p.s. please note that using this way of programming has a lot of pitfalls,
all forms keeps responding so you must prevent re-entrance of events.
 
Rene,

I believe that you are taking the wrong approach to this. Basically,
you should be using an event-based mechanism, instead of trying to mimic
responsiveness while waiting for a response. Basically, you should be
creating the other thread, and performing your work on that thread. Once
the work is done, you can send a notification to the UI thread for updating
(you don't have to worry about it being tied up), and then proceed from
there.

This is pretty much the model for any multi-threaded application. I
believe that the use of DoEvents in this situation is incorrect, and that
using a thread is the correct way to go. Yes, it breaks up your code, but
that shouldn't be a problem if you design your application correctly. Just
look at this as another step in the overall process. All of the steps don't
have to occur in the scope of one function call. If that was the case, we
would have these super-functions which would be quite unwieldly to use.

Hope this helps.
 
Nicholas Paldino said:
This is pretty much the model for any multi-threaded application. I
believe that the use of DoEvents in this situation is incorrect, and that
using a thread is the correct way to go.
Click to expand...

The use of DoEvents in VB6 is the only way since VB6 is not multi-threading
and it is not possible to use ADODB Recordsets among processes. And nothing
worse then users hitting alt-ctrl-del because the application is not
responding.
Yes, it breaks up your code, but
that shouldn't be a problem if you design your application correctly.
Click to expand...

Because the application would use a lot of forms and queries I'm afraid the
application can easily be messed-up when using threads and events for each
data-retrieval making the code hard to understand. There is a lot of classic
data-retrieval (open recordset, while not .eof addrecord/populate) that can
be done without using threads/events, so I will make a design that only for
long running queries threads will be used. This approach might lockup the
application very shortly in some situations when the server is very busy.

Is the ADO NextRecords() still available in .NET?

Rene
 
Back
Top