On Sat, Jul 2, 2011 at 7:09 PM, Alexandros Nipirakis
<anipirakis@gmail.com>wrote:

> What Michael is saying may be completely correct in this situation.
> In my experience the database access doesn't usually really impact the
> user interface until you are pulling a lot of records (I mean tons,
> like thousands).  Or in cases where the data engine is really slow or
> on a really slow network.
>

Yes, I'm pulling around 7000 to 10 000 rows from the Database. I know
someone's going to ask *why*, but I just do.

The user needs to know that the data exists, and generally what the data
looks like.



> But, for the sake of argument, lets say that you don't have a choice
> (that you must pull back a lot of data records, or there are
> performance concerns that our outside of your control).  Ordinarily,
> how you would do this is to pass off the data processing to a
> different thread, using a delegate to call back from that thread to
> update the UI.  IN this case, I don't know (off the top of my head)
> how to do this with a data adapter (because, as I said before, I don't
> use Data adapters) but it will probably involve performing the data
> access, then using a delegate to actually do the fill on the adapter.
>
> Normally, you could communicate using thread safe variables, but
> because you are talking to a graphics thread, you have to use
> delegates.
>
> Unfortunately, there isn't a better way of doing this (IMHO) this is
> tied to the way that .net handles the UI all together.  It causes real
> problems.
>

I agree. I spent some more time on it and used the BackgroundWorker thing
and various invoke methods and finally got it to work. Not perfect, as in
the DataGridView still has to populate the table, which takes a lot of time=
,
but good enough for now.

Thanks!
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.