Question about viewstate

[wsyeager]

I have a grid that I databind with a strongly typed dataset which contains thousands of records retrieved from a database. After the dataset is retrieved from the database, I place it in viewstate. I need to do this because of the following:

A user is allowed to check "x" amount of rows on the grid and submit those records (which causes a postback) to the database for updating. At this point, I grab the dataset from viewstate and simply process those records from the appropriate event. The records in the dataset are processed depending on which rows were checked on the grid. The syncing of rows in the grid to the dataset is exactly the same which is expected.

However, based on the dataset being large, this can reduce performance because of the dataset which was placed in viewstate. If I don't place the dataset in viewstate and grab the records from the database again performing the databind, the rows that the user checked will be lost. Even if I somehow save the rows that were checked via viewstate in between postbacks and apply that to the dataset after the databind, the application runs the risk of the rows being out of sync on the datagrid to the dataset, because some other user could have processed those rows. If custom paging is implemented on the grid, I suppose this would reduce the work load on the data in viewstate which defintely would be acceptable. If not using custom paging, this scenario would still exist.

Can somone please shed some light on whether or not my thinking is correct?
How would one deal with this scenario?

 

[Robby]

Are there changes made by the user to these selected rows?

 

[Derek Stone]

Microsoft SQL Server, which I can only assume you're using, offers a timestamp data type.

The value in the timestamp column is updated every time a row containing a timestamp column is inserted or updated.

You can use this data type to detect and account for changes in records, and increase support for concurrent users, which as far as I can tell, is your greatest concern.

You seem to question the method you're currently using, and you're very much justified. Using view state in that manor is a poor choice, nevermind with that much data.

The best approach to this is to determine if the project absolutely requires this level of functionality. The vast majority of applications do not require each and every update to be checked against the database for the sake of detecting recent changes made by other users. For those of us familiar with ADO and various other database libraries, we know that record locking can and will cause more problems than it will ever solve. I'm not claiming this is what you're trying to do, but history does apply here. By accounting for other concurrent users, the application is going to increase in its complexity. In short, ask yourself if you really need this.

With that said, you'll find that a solution using timestamp columns and notifications to the UI will work quite well. If a user submits changes to a record, simply check the timestamp and prompt them to take further action. Those actions include viewing the current record, merging the records or disposing either the current record or their record. Again, these choices increase the complexity of your application's business logic and presentation layer (the changes to the database layer are actually rather minimal).

 

[wsyeager]

After the data is bound to the grid, the user selects the rows that they want processed. The rows that they want processed can either be updated or not from the grid. There is now way for me to know before hand which rows the user checkedc until a postback occurs. After the user hits a Submit button, I then grab the dataset back from viewstate and begin processing the appropriate checked rows.

Is there a property somewhere where I can specify where the ViewState is to be saved (eg: on the client, etc)?

If I can't save it in viewstate on the server (because of poor performance), maybe I can then try to save it in SessionState on a SQL Server Database via the web.config file...

Microsoft SQL Server, which I can only assume you're using, offers a timestamp data type.



You can use this data type to detect and account for changes in records, and increase support for concurrent users, which as far as I can tell, is your greatest concern.

You seem to question the method you're currently using, and you're very much justified. Using view state in that manor is a poor choice, nevermind with that much data.

The best approach to this is to determine if the project absolutely requires this level of functionality. The vast majority of applications do not require each and every update to be checked against the database for the sake of detecting recent changes made by other users. For those of us familiar with ADO and various other database libraries, we know that record locking can and will cause more problems than it will ever solve. I'm not claiming this is what you're trying to do, but history does apply here. By accounting for other concurrent users, the application is going to increase in its complexity. In short, ask yourself if you really need this.

With that said, you'll find that a solution using timestamp columns and notifications to the UI will work quite well. If a user submits changes to a record, simply check the timestamp and prompt them to take further action. Those actions include viewing the current record, merging the records or disposing either the current record or their record. Again, these choices increase the complexity of your application's business logic and presentation layer (the changes to the database layer are actually rather minimal).