Heya Rick,

Dead on. It's very hard to distribute shrink-wraps when you have no control over the data engine installation process and little control over how it might interact with what's already installed and/or security issues.

What strikes me is that it seems we're looking backwards with fondness to the days when data storage was intrinsic to the OS, such as it was with IBM, DEC, and VAX machines 30 years ago. You didn't worry about the data store then it was just "there".

At some point...maybe it was the birth of DOS or CP/M themselves, files and data were divorced and now tools can mung internal data fairly well but there's a wall or interface ot persistent data.

Sure that wall exists with VFP but it's a not overwhelming because VFP manages accessing the data internally once the actual physical files are extant.

IMHO, the MS .Net team still has a long ways to go to get over this hump.

>
>>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?
>
>The ASP.NET databinding that is built in is pretty pathetic and there's not that much that has changed philosophically in databinding in ASP.NET 2.0 over 1.x. I'm not sure what you mean by persistent here there's nothing persistent (other than storing your data in ViewState) about databinding in ASP.NET.
>
>The controls can bind to anything anwya so whether the data comes directly from the server or through some internally generated mechanism is irrelevant.
>
>In any case, my point is that there are many scenarios where data comes down from the server and needs to be manipulated on the client for formatting, filtering and general data manipulation all of which is not easily done with ADO.NET. It can be done but, if you had the simple ability to re-run a query against data that was pulled into a DataSet you would reduce the amount of code you have to write drastically. Maybe you haven't done a lot of manipulation of data in ADO.NET where data needs to move from one table to another and that sort of thing is not pretty nor even anywhere near as automatic as it should be. Try out some simple data mapping routines where you need to build a second table on the fly and move the data from a first one into... it takes a fair amount of code to do such a simple thing that could be handled with a simple SQL statement.
>
>This is not a common scenario, but when it does happen you realize what is missing in ADO.NET. I work with ADO.NET extensively these days, and while I feel it totally adequate for the common scenarios, this is one scenario that truly sucks. Heck there's not even decent support for moving a DataRow from one DataTable to another without breaking concurrency rules.
>
>The workaround for it is to do as much as possible on the server which often is *not* the most efficient way to do things, especially if complex business rules are involved.
>
>>
>>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.
>
>Have you ever built consumer level applications or small business shrink wrap application? Something not geared at a large company? Other than larger companies, NOBODY wants to install and maintain a SQL Server or MSDE or SQL Express. Besides the fact that you increase the size of your distribution considerably it's just not a very realistic scenario for small applications.
>
>I have several products that have small data needs, but they still need a database. Example: Help Builder. Can you imagine me selling Help Builder and Requiring users either to have SQL Server Express or forcing them to install it? I can't... If I did it would probably reduce my potential market by less than half.
>
>I have another couple of verticals that are similar - a small time tracking app - same thing. It's a small utility app - it needs a database but surely not a huge engine like SQL Express that runs at 30 megs memory usage and takes 50 megs to install not even mentioning the downlaod requirements. The app is 300k and I'm supposed to install a 80 megs of files to access a few thousand records?
>
>As it is I have to use third party tools and they actually work well. But it seems that this sort of thing should be built into the toolset. Microsoft is aware of the issues on this topic as well. There are a number of people working on just that aspect although it may not turn out to be an 'externally' accessible engine.
>
>Mike - I agree that using SQL Server for most business and Web applications makes good sense. I use SQL Server for just about everything I built for my own business and for my clients.
>
>But there are a *many* perfectly legitimite reasons for a local data engine, if for nothing more than a mechanism to easily persist data and reuse it efficiently. Xml isn't it because it falls apart once the data size gets over a certain limit.
>
>There's more to development than just the corporate world with IT departments that have the time and money to spend on administering and paying for SQL Servers. <g>
>
>>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.
>
>That's great. I found the same thing with ASP.NET. So much so that I brought an ASP.NET type coding model back to the Fox version of Web Connection 5.0 <g>...
>
>+++ Rick ---