Well, if performance is the issue, you might want to consider using
datareader instead of dataset. But datareader works very differently
than dataset (and dataview) because DataReader is connected way to
access data(forward-only, read-only). Still it can be bound on DataGrid.


If you choose to use datareader then you really are dependent on
postbacks (DataReader can be read only once so every post back requires
re-opening datareader etc...)

And your questions:
1. I think this just is the way how it works (postback). You have on
next question already got the point that  data caching etc. could help.
Solution is to just mix available techniques so that result is the best
compromise. =3D) The "right" solution depends so much of your
application's task and data that it's quite hard to tell any precise.
You'll have to find it yourself for your application.

2. Data caching's performance drawback depends where you are going to
cache objects and how. In Session,Application,Cache or  Viewstate or
somewhere else.

With Session drawback is just that server has to keep everything (object
per user) in memory(or different machine/SQL Server if ussing different
session store) for every user. More users, more load. Of course it
depends the size of object to cache too.

With Application there's only one object to cache, but then becomes the
multi-user handling if data is going to updated (every user has access
to same object that is cached in Application level). Multiple using has
to be handled in object itself or using locking by Asp.NET (Application
Lock or SyncLock...).

With Cache object the idea is same as with Application but there's more
choices because of possibility to use dependencies (to reload data to
cache after expiration etc.).

With Viewstate your page gets slower when size of the cached object
increases. Viewstate stores data in aspx page in hidden form field and
sends it back on every postback.

But there are other solutions for this to reduce server's load. For
example dataset can be stored on some cache (for example session) in XML
string and on every postback to read it back. This way you are only
storing string not whole object (of course there's drawback in
recreating object, but I have found this quite fast way to store
datasets).

3. Consider dataview as a "view" just like in database. It's a view of
data in DataSet's dataTable (one DataView per DataTable). Via DataView
you can get finer control on how Datatable's data can be updated etc.
DataView gives the possibility to sort data without requerying it from
database and using SQL's ORDER BY. DataView can be bound on DataGrid as
well as dataSet (actually when you are databinding DataSet's datatable
you are under the hood binding datatable's view (defaultview property)
which is dataview for that table.).

HtH

Teemu Keiski

-----Alkuper=E4inen viesti-----
L=E4hett=E4j=E4: Kan Yu Ting [mailto:yu-ting.kan@p...]
L=E4hetetty: 16. kes=E4kuuta 2002 18:57
Vastaanottaja: ASP+
Aihe: [aspx] DataView and Dataset and performance issues


Hi all,

My current application bind a dataset to the datagrid with about 500
records with about ten fields. I put the datagrid within a <div> and
make
it overflow such that paging is not used. The datagrid have a
BoundColumn
which shows a image while selected.
I found that the speed is quite slow for doing each round trip?

My questions are:
(1) For just simple action, like highlighting the selected row, the
round
trip need to post back all data. Are there any typical solution to
tackle
this problem?

(2) For data caching, what's the drawback? How's it affect server
resources?

(3) I am confused by DataView and DataSet. One can directly bind DataSet

to grid. What's dataview for and would DatSet a solution for performance

through sorting or sth else and How?

Thanks a lot

Kan

Thanks a lot. You really help me figuring out different implementation 
choices.

:)
Kan

 Well, if performance is the issue, you might want to consider using
datareader instead of dataset. But datareader works very differently
than dataset (and dataview) because DataReader is connected way to
access data(forward-only, read-only). Still it can be bound on DataGrid.


If you choose to use datareader then you really are dependent on
postbacks (DataReader can be read only once so every post back requires
re-opening datareader etc...)

And your questions:
1. I think this just is the way how it works (postback). You have on
next question already got the point that  data caching etc. could help.
Solution is to just mix available techniques so that result is the best
compromise. =3D) The "right" solution depends so much of your
application's task and data that it's quite hard to tell any precise.
You'll have to find it yourself for your application.

2. Data caching's performance drawback depends where you are going to
cache objects and how. In Session,Application,Cache or  Viewstate or
somewhere else.

With Session drawback is just that server has to keep everything (object
per user) in memory(or different machine/SQL Server if ussing different
session store) for every user. More users, more load. Of course it
depends the size of object to cache too.

With Application there's only one object to cache, but then becomes the
multi-user handling if data is going to updated (every user has access
to same object that is cached in Application level). Multiple using has
to be handled in object itself or using locking by Asp.NET (Application
Lock or SyncLock...).

With Cache object the idea is same as with Application but there's more
choices because of possibility to use dependencies (to reload data to
cache after expiration etc.).

With Viewstate your page gets slower when size of the cached object
increases. Viewstate stores data in aspx page in hidden form field and
sends it back on every postback.

But there are other solutions for this to reduce server's load. For
example dataset can be stored on some cache (for example session) in XML
string and on every postback to read it back. This way you are only
storing string not whole object (of course there's drawback in
recreating object, but I have found this quite fast way to store
datasets).

3. Consider dataview as a "view" just like in database. It's a view of
data in DataSet's dataTable (one DataView per DataTable). Via DataView
you can get finer control on how Datatable's data can be updated etc.
DataView gives the possibility to sort data without requerying it from
database and using SQL's ORDER BY. DataView can be bound on DataGrid as
well as dataSet (actually when you are databinding DataSet's datatable
you are under the hood binding datatable's view (defaultview property)
which is dataview for that table.).

HtH

Teemu Keiski

-----Alkuper=E4inen viesti-----
L=E4hett=E4j=E4: Kan Yu Ting [mailto:yu-ting.kan@p...]
L=E4hetetty: 16. kes=E4kuuta 2002 18:57
Vastaanottaja: ASP+
Aihe: [aspx] DataView and Dataset and performance issues


Hi all,

My current application bind a dataset to the datagrid with about 500
records with about ten fields. I put the datagrid within a <div> and
make
it overflow such that paging is not used. The datagrid have a
BoundColumn
which shows a image while selected.
I found that the speed is quite slow for doing each round trip?

My questions are:
(1) For just simple action, like highlighting the selected row, the
round
trip need to post back all data. Are there any typical solution to
tackle
this problem?

(2) For data caching, what's the drawback? How's it affect server
resources?

(3) I am confused by DataView and DataSet. One can directly bind DataSet

to grid. What's dataview for and would DatSet a solution for performance

through sorting or sth else and How?

Thanks a lot

Kan