Hi All,
in old asp i think there was a smart solutions than datagrid now
what i mean :
when oneditcommand,onitemcommand,ondelete,onupdate,onca ncel
all these events i have to call the database for each events
a heavy calling for the db server

the bad events in those is onEditCommand why i need to bind data to grid.

Any Comment

Ahmed Ali
Software Developer

__________________
Ahmed Ali
Senior Software Developer

I'm not sure how you mean that old asp had a smarter solution.

You have to bind the datagrid when you change things like selected item index or edit item index so the datagrid redraws the items correctly. However you do not *have* to hit the database again if you have your data available locally. You could cache a dataset/datatable or save the result of a query to an xml file so that you don't have to hit the database again. Then you can rebind the datagrid from that. However, then you'll have to deal with the potential for stale data.

writing to files need authorization from the web server and added time when write/read from files(slow the performance)

So ..
is there a way to write more client scripts two avoid calling dbServer
or any Sites that supports a PreMade Datagrids

Ahmed Ali
Software Developer

Yes, files do require some overhead, however, accessing the database does as well, and seeing as the database system would use files, it would be more overhead than just a file. That's why I suggested using a cached dataset.
This results in significant speed increase, but you sacrifice the up-to-date nature of the data. If you can live with a possible lag in data, then you could use cached data. There are plenty of methods that you could use to keep the cached data up-to-date with the database such as a file dependency on a file that is modified when the database is modified.

There are lots of ways to deal with this issue on the client side that would eliminate the need for postbacks and server side processing. That would get into the area of javascript and DHTML however, which is beyond the scope of this particular forum category.

I personally am willing to sacrifice the performance of postbacks for the increased development efficiency and reduction of headaches getting whiz-bang client-side stuff to work.

thx Peter,
as you say
 

i am asking is it possible to depend caching on database changes????


Ahmed Ali
Software Developer

Not directly (yet, SQL server yukon will supports cache ties to data).

Two techniques that jump immediately to mind are:
a) The code that modifies data that is cached can expire/remove the cached item.
b) The cached item is dependant on a file, and this file is "touched" by the data update code.

In the scenario of a complete web application, method A is probably the most sensible as it removes the complication and overhead of file access. Any time database data is updated, force the cached dataset to expire or remove it from the cache. Then the next request for it will automatically update it. Also, you could just update the cached item in the same update code.