This is the first time I ever remember honestly disagreeing with you, or at least being confused by what you say. It's probably just my ignorance....

Why do you want "easy ways to requery data once it's been pulled down from the server" now that we have server-side data bound controls in ASP.NET 2.0? To me the whole point is that they're automatically persistent. The user updates one control after another, the values all stay there. No muss, no fuss. Are there avoidable round trips I'm not thinking of?

Likewise, I don't get what you mean about local datastores being a must for vertical apps. Can you enlighten me? Why would I want to store data in retrograde DOS thingamabobbies when I can store it in a real database? I am not being antagonistic, just not following you.

BTW, the web development project I was pumping your brain about a couple months ago is off the ground and I am immersed in it. Having a blast.


>Hi Mike,
>
>>Do you know a lot of companies these days who WANT local data storage? I don't. That train left the station a few years ago, unless you're talking about the mom and pops.
>
>The issue isn't a local data store. The issue is storing result data in a local data store as opposed to loading everything up into memory which is finite and has serious performance limitations once your data sets returned from a query get large.
>
>In addition, .NET currently lacks easy ways to requery data once it's been pulled down from the server, and a local data store would make that a lot easier for the .NET data teams to implement.
>
>And don't discount local datastores either. For any kind of vertical application a local datastore is a MUST. Or any kind of consumer application for that matter. .NET being a general purpose programming tool, should be able to address that market but it doesn't - you need to rely on third party tools (VistaDb, SqlLite etc.)...
>
>If a local data store was available you better believe that it would be used for many things! Rightly or wrongly <g>...