Not that I think that this is the right place for this kind of discussion - but I will bite. First off, Solar - I would STRONGLY suggest you join a .Net board of some sort, this will be infinately more useful than posting here (IMHO). Use http://stackoverflow.com/ or similar, they have a bunch of people who are really good Microsoft people. The Microsoft forums are also quite good, and there are plenty of examples of doing (basically) what you are looking to do on the internet. I want to preface what I am about to say with the following: 1. I have never had formal training in .Net. I am largely comenting on my own experience writing .Net applications for the past six years. 2. I have had limited classes in Computer Science. My programming knowledge (I am a paid business programmer) come from the past seven years working professionally as a programmer. What I am saying may or may not be technically perfect, but it is (none the less) my personal experience with .Net. 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. I have succesfully used a single threaded application for most of my data access needs. The one time I had to use the separate thread (recently) was when I needed to pull data over a relatively slow WAN link. Before that, I was going through a complex BOM struture and importing it into a different data system which (as you might expect) would have seriously impacted performance. In your case, it may be that presenting data differently (for instance, getting a record count and asking if the user really wants to pull that size of a dataset) or perhaps using a paging system (this is how the Oracle SQL Developer works by the way). 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. Regards, Aleksei On 2 July 2011 18:23, Michael Watterson wrote: > On 02/07/2011 22:29, V G wrote: >> How can I make thread safe calls to the form controls? I can't really fi= nd >> this information anywhere. Well I can, but I had trouble getting it to w= ork. >> Specifically setting the data source, etc. A nice little example would b= e >> much appreciated. > > Pretend you never heard of mult-threading and think again how your GUI > works. > > =A0> "it locks up the program for a minute every time new data has to be > displayed." > > That's not something you should solve by multi-threading. > > The ONLY time ever in writing PC software I needed multi-threading was > when I wrote a platform engine in Modula-2 for DOS on 286. Since it was > the only program running it had it's own mini-OS and co-operative > multitasking to do sample play pack on PC speaker via PWM, Sound card > wav and midi, animated sprites (each with own process) and scrolling > foreground slower scroll backdrop and static background at infinity. > > You don't need multi-threading for GUI + database. Something else is wron= g. > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .