Hi
First, I'm not against NET, from what I saw is cool stuf there :-)
What I believe is that is much easy, NOW, to design and develop high performance and flexible database applications using VFP than using NET. If someone demonstrates the contrary, is OK, I'm not a fanatic guy.
Mike started one thread on this (Fox vs. ADO.NET + SQL Server), let's see .

>None of this is "news" ... it's simply an extension of DAO and "old" ADO.
>
>For that matter, VFP cursors and views are handled in "memory" until they get "too big"; then VFP starts creating tempory datasets.
>
>As some point, ADO.NET will also create "tempory datasets" ... even if only in the form of virtual memory; in either case, it means going to local disk.
>
>And as with VFP, you should think hard before you start dragging "thousands of records" down the wire.
>
For local phisycal storage, I thought about local tables.
For the project I'm working now, I use the following approach (it must work well over a DSL connection):

Download thousands of records ONCE to local tables (all that means lookup or static tables).
If these tables are modified at server side, get only changes from server log tables (implemented via triggers) and apply to local tables. The communications is made using a compressed tunnel utility (ZeBeDee).
Use this local tables for instant lookups/selections in our customers table (>2000) or products list >40000, categories, etc, and for working offline if all needed for entering transactions exists locally.

In VFP help, topics:
"Client/Server Design for High Performance"
"Data Location on the Optimal Platform"
"Optimizing Access to Remote Data"

Is something like described in these topics possible in NET now?


>>Hi
>>While I agree that a ADO.NET data set can represent an IN MEMORY database and we can add,edit records, relations and so, all these are IN MEMORY? What about local physical storage? What about handling thousands of rows? We need to save the dataset data to a local XML and load it again?
>>I dare to say that, if we can say that ADO.NET has a "data engine", we cannot say that has a "database engine"
>>Anyway, Codebase is available for .NET with properties and methods that can be used for local database acces (DBFs). It can be integrated and compiled to managed code (at least this is what they say).