>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.
Nancy,
No! Don't sweep DataReader from your brain. Actually now thinking at home I realize DataReader is still the way and you need no cache there (as I remember it'd be OK for you if you see the initial list for the life of session).
With VFP we could simply do:
select myTable
scan
myListBox.AddItem(...)
endscan
No data binding after that and we don't need the table. I think it directly maps to datareader usage:
SqlConnection con = new SqlCon...
while (myReader.Read)
myList.Items.Add(...);
myReader.Close();
Then list is an unbound one that doesn't need any caching.
Yes, I'm caching data that's changing. I'm not sure if it's fast for I'm currently using localhost. If it's not an illusion then it's really fast (I was never happy with ASP being slow -amazed with ASP.Net) - didn't do any benchmarking or monitoring what comes and goes.
Cetin