>Cetin-
>
>>Suggesting cache instead of session just because new caching services seemed to me more appropriate then using old session vars. Cache and enableviewstate and multiple users would benefit it I think.
>
>I reread some of the documentation about caching.
>
>>DataReader? Isn't it closed after first read? Even somehow it's still open wouldn't it be at 'eof'? I think you mean dataset or something like that.
>
>The DataReader is open after the session variable is restored. But, you're right that the DataReader is restored HasRows == true and Read() == false. A little history...I started out using a dataset, but because of some of the things I read trying to assess what the best way was to manage this particular bit of data, in combination with the dropdown control, I switched to a datareader, although I was suspicious of this very state. However, I just don't undestand clearly enough what exactly happens when a dropdown is bound to a datareader. Since everything seemed to indicate a datareader + dropdown + webform would be a grand idea, I went with it. I think I should have stuck with my suspicions instead. <s>
>
>Anyway, my conclusion is, don't use datareaders + sessions vars. And datareaders + caching are a no-no, based on http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/CachingArchch4.asp.
>
>Okay, so lession learned there. As for using the cache versus session variables generally...I *think* that caching does not necessarily _replace_ session vars.
>
>Leaving aside this one datareader issue, I'd initially passed on caching my datasets because almost all of it is at least somewhat volatile. Although some is rather static. For example, a list of classes for a registration site. The class list does change, but not rapidly. However, the current number of registrations does rapidly change and has to be up-to-date so I can show the students what classes are closed. There's a lot of calculation that's done, and while no one minds the rate the pages load (it's not _that_ bad) I know it should be more responsive. So, caching would help that, but, and this is my own ignorance, of course, how to make use of caching? I didn't think it was possible. But, the link above says datasets "can be updated without needing to reinsert them into the cache. Because you cache a reference to your DataSet, your application can update the data without the reference in the cache needing to change."
>
>Sooooo, well, I guess I'll have more reading to do, but any of your additional thoughts on the subject would be welcomed.


Nancy,
I still feel I'm only wetting my feet with .Net, so I can easily direct you irrelevant things:)
The source you pointed is nice (and the one I was going to point you was the 2nd in list).

Here is what I know about DataReader in a nutshell:
-DataReader is for fast forward read. (analogy scan ... endscan IMHO).
-They block the connection they're used with (if you just read 2 rows and left it there, some other task might not use the connection until it's released). From this point I look at it as holding locks on a table (ADO was doing it too but was opening 'hidden' connections behind the scenes, ADO.NET doesn't).
-However a datareader is the fastest way to fill in a dataset or datatable and here for you was the right choice (except keeping it open). I do too create a ds or dt on the fly and read into it then cache the ds/dt.

To me using Cache class looked more OOPish:) and they might add to it anytime. If you ask my understanding about it, no didn't understand yet - but I'm trying.
PS: Check 2nd one too. There it's showing another way with hidden frames.
Cetin