I'm not talking about a table. I'm talking about using Session/Cache values for this. THe overhead to go to SQL is among the most expensive operations in ASP.Net so avoiding a trip to the backend will reduce this. Not that it's that expensive, but relatively speaking that is.

Sql Server Sessions are expensive - the better choice if possible is StateServer or even InProc if the app is running on a single server and doesn't require frequent restarts.

+++ rick ---


>>In most cases you can count on Serialization being faster than going back to the backend...
>>
>>However, the right place to dump this stuff more likely is going to be the Cache object for most reusable things. Storing data on a per user level is going to be too fat for most applications - too much data stored memory (with both InProc and StateServer state stores).
>>
>
>Why wouldn't you just use SQLServer state store for the serialized objects? I don't quite understand the point of creating your own table and storing the session data in your table, where you will have to access the database on each page request.
>
>Morgan