best way to refresh a dataset.

[jaYPee]

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.

[Joyjit Mukherjee]

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" <hi******@yahoo.com> wrote in message
news:0k********************************@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.

[Cor Ligthert]

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" <jo**************@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" <hi******@yahoo.com> wrote in message> news:0k********************************@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.>>

[Cor Ligthert]

Something went wrong it seems.

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

However just my thoughts,

Cor

[jaYPee]

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"
<no************@planet.nl> wrote:

Something went wrong it seems.

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

However just my thoughts,

Cor

[Jonas Pohlandt]

> 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?

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.

[jaYPee]

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"
<j.******************@dbit-systems.de> 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").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?

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.

[Joyjit Mukherjee]

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" <no************@planet.nl> wrote in message
news:Oj**************@TK2MSFTNGP09.phx.gbl...

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" <jo**************@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" <hi******@yahoo.com> wrote in message>
news:0k********************************@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.>>

[Cor Ligthert]

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" <jo**************@hotmail.com>

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" <no************@planet.nl> wrote in message
news:Oj**************@TK2MSFTNGP09.phx.gbl...

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" <jo**************@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" <hi******@yahoo.com> wrote in message>
news:0k********************************@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.>>

[Cor Ligthert]

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" <hi******@yahoo.com>

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"
<j.******************@dbit-systems.de> 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").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?

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.

[Jonas Pohlandt]

> 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).

What do you mean by "you need to pull out all the data into the dataset"?
If you want to display 50k rows in your grid, then yes, you'd have to
populate the dataset with 50k rows. I just wonder, why would you like to
show 50k results? I think that is hardly usable. On the other side, I don't
know what you're doing in your app. If you want only want filtered results
to be shown in your grid, filter in the stored procedure and thereby reduce
the amount of data you have to populate your dataset with.