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").Clear()
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.

Hi,

if the data to be loaded to the dataset is relatively large, the best way of
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 thread know
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/is...asicInstincts/

Regards
Joyjit

"jaYPee" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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").Clear()
> 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.

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 events
are a much better way to do this.

http://msdn.microsoft.com/library/de...nts.aspHowever just my thought, and when I see something wrong tell me?Coir"Joyjit Mukherjee" <(E-Mail Removed)>> 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" <(E-Mail Removed)> wrote in message> news:(E-Mail Removed)...>> 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").Clear()>> 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.>>

Something went wrong it seems.

http://msdn.microsoft.com/library/de...iderEvents.asp

However just my thoughts,

Cor

Thanks a lot. But I think this is not what I am looking for.

I made a lot of research regarding this problem and I saw so many
threads that has the same problem. I think this is cause by a
disconnected dataset. If I will use the data reader the disadvantages
is that it is a forward only. Which means that I can't update it.

I am now looking for an alternative on how can I insert the new
records to my table called "schyrsemcoursejoin" based on the other
table called "coursetemplate".

Because if I use stored procedure I have to fill the SqlDataAdapter
again and this takes a lot of time to process.

On Thu, 18 Nov 2004 09:27:12 +0100, "Cor Ligthert"
<(E-Mail Removed)> wrote:

>Something went wrong it seems.
>
>http://msdn.microsoft.com/library/de...iderEvents.asp
>
>However just my thoughts,
>
>Cor
>

> 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").Clear()
> 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?

I use the SqlDataAdapter a lot. In my experience the actual .Fill is very
cheap. Most of the time is used up by sqlserver executing the sproc. At
least, that's my experience. I do the .Fill directly on the datatable
though, not on the dataset, maybe that saves some time (seems unlikely
though).

Something like

dim dt as DataTable = ctype(myGrid.DataSource, DataTable)
dt.Clear
mySqlAdapter.Fill(dt)

You should check how much time it takes for your sproc to execute. That's
where I solve most performance issues -> TSQL optimization. Allthough I have
to say I never had to deal with resultsets >> 1000 rows, so maybe that's why
I never had any problems with the SqlDataAdapter.

Hi,

In my part it's not the stored procedure that executes a lot of time.
It is the fill method of an sqldataadapter that takes longer time to
execute.

May be that's why you don't have a problem refreshing the dataset
again because you are not dealing with more than 1000 rows. My table
as of now contains more than 50,000 records. So as what I have learn
(correct me if i'm wrong) you need to pull out all the data into the
dataset. One more thing is that this table is related from the other
table (a.k.a. parent/child).

On Thu, 18 Nov 2004 16:03:48 +0100, "Jonas Pohlandt"
<(E-Mail Removed)> wrote:

>> 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").Clear()
>> 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?
>
>I use the SqlDataAdapter a lot. In my experience the actual .Fill is very
>cheap. Most of the time is used up by sqlserver executing the sproc. At
>least, that's my experience. I do the .Fill directly on the datatable
>though, not on the dataset, maybe that saves some time (seems unlikely
>though).
>
>Something like
>
>dim dt as DataTable = ctype(myGrid.DataSource, DataTable)
>dt.Clear
>mySqlAdapter.Fill(dt)
>
>You should check how much time it takes for your sproc to execute. That's
>where I solve most performance issues -> TSQL optimization. Allthough I have
>to say I never had to deal with resultsets >> 1000 rows, so maybe that's why
>I never had any problems with the SqlDataAdapter.
>

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
events
> are a much better way to do this.
>
>
http://msdn.microsoft.com/library/de...nts.aspHowever
just my thought, and when I see something wrong tell me?Coir"Joyjit
Mukherjee" <(E-Mail Removed)>> 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" <(E-Mail Removed)> wrote in message>
news:(E-Mail Removed)...>> 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").Clear()>>
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.>>
>

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" <(E-Mail Removed)>


> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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
> events
>> are a much better way to do this.
>>
>>
> http://msdn.microsoft.com/library/de...nts.aspHowever
> just my thought, and when I see something wrong tell me?Coir"Joyjit
> Mukherjee" <(E-Mail Removed)>> 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" <(E-Mail Removed)> wrote in message>
> news:(E-Mail Removed)...>> 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").Clear()>>
> 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.>>
>>
>
>

jaYpee,

When it is not for one time loading on a PDA or something, it is not a good
approach to use such huge datasets.

You would better cut your dataset in usable formats, where you can think on
about 200 datarows as goal.

The loading of that huge dataset is in a multiuser environment probably only
the first problem you will be confrontated with. There will be much more
going on in my opinion.

Just my thought,

Cor

"jaYPee" <(E-Mail Removed)>

> Hi,
>
> In my part it's not the stored procedure that executes a lot of time.
> It is the fill method of an sqldataadapter that takes longer time to
> execute.
>
> May be that's why you don't have a problem refreshing the dataset
> again because you are not dealing with more than 1000 rows. My table
> as of now contains more than 50,000 records. So as what I have learn
> (correct me if i'm wrong) you need to pull out all the data into the
> dataset. One more thing is that this table is related from the other
> table (a.k.a. parent/child).
>
> On Thu, 18 Nov 2004 16:03:48 +0100, "Jonas Pohlandt"
> <(E-Mail Removed)> wrote:
>
>>> 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").Clear()
>>> 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?
>>
>>I use the SqlDataAdapter a lot. In my experience the actual .Fill is very
>>cheap. Most of the time is used up by sqlserver executing the sproc. At
>>least, that's my experience. I do the .Fill directly on the datatable
>>though, not on the dataset, maybe that saves some time (seems unlikely
>>though).
>>
>>Something like
>>
>>dim dt as DataTable = ctype(myGrid.DataSource, DataTable)
>>dt.Clear
>>mySqlAdapter.Fill(dt)
>>
>>You should check how much time it takes for your sproc to execute. That's
>>where I solve most performance issues -> TSQL optimization. Allthough I
>>have
>>to say I never had to deal with resultsets >> 1000 rows, so maybe that's
>>why
>>I never had any problems with the SqlDataAdapter.
>>
>