Hi Doug,

ViewState is fine to use if you don't care about security and if the dataset is small because the data is stored in the page itself. You don't want that page getting too large.

The Data Caching is mostly used when you need to cache data application wide to improve performance when data won't change as often. However, it can be used as an alternative to Session State or ViewState on a per Session basis. You would clean up the XML file in the Session_End event located in the Global.asax file.

My preference would be to use Session State or ViewState but only if the data was small. However, the data really should be small in the first place.

>Cathi,
>
>Which would be the best technique? I always use ViewState. Is one more efficient than the other? It would seem that there is a whole lot of overhead of creating, writing and reading an XML table. Is ViewState just as heavy behind the scenes? How would you clean up the XML files once you were 'Done'?
>
>Just Wondering,
>Doug
>>One approach you can take is to use Data Caching. The data would be persisted on the server as XML files. You would use the SessionID to isolate the caching on a per session basis. Keep in mind that this approach does not work on web farms. Here is a link to an article that explains how this would work:
>>
>>http://www.dotnet247.com/247reference/a.aspx?u=http://msdn.microsoft.com/msdnmag/issues/01/12/cutting/cutting0112.asp
>>
>>>All,
>>>
>>>I am looking for a way to persist a dataset between postbacks without using session variables.
>>>
>>>Is there a best practice for this?
>>>
>>>TIA
>>>
>>>Rex