Joyjit,
I am not agains using multithreading, in the oposite I use it, however
sometimes I get in this newsgroups the idea that it is overdone. The case of
loading or updating a dataset is such a situation. The calling process is
completly dependable of the result of that procedure and nothing can be done
between. When that is an update even not a close what becomes possible when
the UI is not waiting on the result, however can be closed in between.
However just my thought,
Cor
"Joyjit Mukherjee" <joyjit_mukherjee@hotmail.com>
[color=blue]
> Hi Cor,
>
> the main benefit is improved user experience. An end user feels more
> comfortable to see a message like "Please wait while data is been loaded"
> while the background thread populates the dataset than seeing the screen
> freezing during the activity. Also, you can proceed with doing something
> else as the main thread is not blocked.
>
> Yes, you are right, database & data adapter errors are not caught directly
> because you have very little control over async operation. Still you can
> set
> some properties to get those later for proceedings.
>
> Basically, the implementation models for both the async callbacks & events
> are same, they use delegates. But you have two different approaches to go
> as
> per your requirements.
>
> Thanks
> Joyjit
>
> "Cor Ligthert" <notmyfirstname@planet.nl> wrote in message
> news:Oj9xmVUzEHA.1308@TK2MSFTNGP09.phx.gbl...[color=green]
>> Joyjit,
>>
>> I have readed this often. Can you tell me what is the benefit from this,
>> with this sample you now have to monitor that the work is done.
>>
>> The user is only interested that his screen is not freezed but while
>> doing
>> this can see something.
>>
>> It looks for me a nice method for the programmer who can be very proud on
>> it, however for the enduser it gives in my opinion not any benefit except
>> that he can close his application while the datagrid is updating.
>>
>> Which means that when there are errors those are never catched and your
>> database has errors somewhere in the middle. (Which can be catched in the
>> thread of course as well however makes it only more difficult, because of
>> the communication with the UI )
>>
>> I think that when you want this kind of things using the dataadapter[/color]
> events[color=green]
>> are a much better way to do this.
>>
>>[/color]
>
http://msdn.microsoft.com/library/de...nts.aspHowever
> just my thought, and when I see something wrong tell me?Coir"Joyjit
> Mukherjee" <joyjit_mukherjee@hotmail.com>> Hi,>> if the data to be loaded
> to
> the dataset is relatively large, the best wayof> calling the fill method
> is
> via a callback method asynchronously which will> create a separate thread
> to
> run in parallel with the main thread. When the> new thread is finished the
> callback mechanism will let the main threadknow> that the operation is
> finished, so that you can show the results. See more> in this recent MSDN
> magazine article: ->
> http://msdn.microsoft.com/msdnmag/issues/04/01/BasicInstincts/>> Regards>
> Joyjit>> "jaYPee" <hijaypee@yahoo.com> wrote in message>
> news:0kfop0d60eluv6hbh5k5n8h4ihhjutuo74@4ax.com... >> I have a function
> that
> call a stored procedure which performs an>> insert command. now i want to
> refresh the dataset so that the newly>> inserted data will be available to
> my datagrid>>>> I have tried to call>>>>
> DsStudentCourse1.Tables("SchYrSemCourseJoin").Clea r()>>
> SqlDataAdapter3.Fill(DsStudentCourse1)>>>> However, the fill method causes
> a
> lot of time to process.>>>> anyone know what is the best way to
> fill/refresh
> the dataset again so>> that the newly inserted records will be available
> to
> my datagrid?>>>> thanks in advance.>>[color=green]
>>[/color]
>
>[/color]
