julielerman

Hey Kemal,

re #1, I can't get past "1million rows". I would never dream about pulling that much data across teh wire into an application. The point of using notracking is to use EF to retrieve data that is read-only. No need to waste resources asking EF to track that data. I recall some  unexecpted (to me) but expected to EF behavior where it can lazy load from objects that were queried with no tracking. I cannot remember...I'd have to go look in one of my books (yes, I have to do taht) or just try it again.

re#2: dependent on what that behavior is about notracked and lazy or possibly exlicitly loaded objects that I just mentioned.

re 3... Acch...that one I cannot answer off the top of my head. It would take some experimenting to answer. That's how I have to learn. If you have some time to do some testing on that one, I'd be interested in your discoveries. Sorry I just had a brief moment to stop by and those last two questions take a lot more thought.

Thanks Kemal! It was nice meeting you on twitter! Just to clarify for newbies: lazy loading is optional with EF. It requires a combination of telling the DbContext instance that you want to enable lazy loading (DbContext.Configuration.LazyLoadingEnabled) which you can do as needed or even in the constructor of the context) PLUS any navigation properties that should take advantage of lazy loading need to be marked virtual. So if the property is marked virtual, but you don't have LL enabled, it won't work. (and the other way around). Since I had no need for lazy loading, I didn't bother with "virtual" in my examples. (P.S. in VB that's Overridable )

haha Alex! Can I hire you as my publicist?