tag:blogger.com,1999:blog-4214922889450630344.post4335973126479761225..comments2008-06-30T10:21:59.158-07:00Robin Clowershttp://www.blogger.com/profile/09558658468617627887noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-4214922889450630344.post-50823653864879886912008-06-30T10:21:00.000-07:002008-06-30T10:21:00.000-07:00Thanks for the comment Will! I agree that using ToList is the most intuitive way to solve this, but it definitely acheives the desired effect. Bindable LINQ looks really interesting, I have not tried using LINQ in a connected scenario, so I was unaware of those issues.Robin Clowershttp://www.blogger.com/profile/09558658468617627887noreply@blogger.comtag:blogger.com,1999:blog-4214922889450630344.post-6223307964923490172008-06-26T08:19:00.000-07:002008-06-26T08:19:00.000-07:00I've had a bunch of weirdness with LINQ caching - although most of mine have been around stored procs. <BR/><BR/>The .ToList() method, whilst crude, seems to be a good way to bypass a raft of issues. <BR/><BR/>The main drawback I found is that unless you're using something like <A HREF="http://www.codeplex.com/bindablelinq" REL="nofollow">Bindable LINQ</A> you've just broken any eventing notifications right there should you subsequently update rows. <BR/><BR/>Obviously it's not that important for ASP.NET and other backend services, but is more important for WinForms/Silverlight/WPF.Will Hugheshttp://www.blogger.com/profile/09080693385564136927noreply@blogger.com