Cetin-

>I still feel I'm only wetting my feet with .Net, so I can easily direct you irrelevant things:)

Well, you'll have a hard time mis-directing me more than I do myself. :-)

>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).

Right.

>-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).

Right.

> 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.

Yes, though, I've struggled with that royal "guideline" that said use datareaders for readonly data. I think I'm going to purge that idea from my brain.

>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.

Yep. I'm very interested in it. You're caching data that is changing?

>PS: Check 2nd one too. There it's showing another way with hidden frames.

Will do.