Hi dorin,

I have little doubt that this gap indeed will be filled in someway at some point, and of course all kinds of third party solutions are comming up to provide a more convenient way of hanlding data. However, IMO, it still is too early to conclude that .NET is mature enough for this arena. There has to get a standard in handling relational data efficiently. Until that point all data handling mechanisms are propetary and for a important platform like .NET this is not a desired thing. If there is a standard which efficiently handles local data we finally can establish some general practises of how to handle local relational data in .NET applications as opposed to everyone doing it their way. a .NET developer would directly learn from the beginning of the learning curve (published articles on MSDN) how to handle this area. Also .NET by standard would include this local databse engine so with each update of .NET, the it is also updated and does not suffer from versioning problems.

When this is the case you might have a platform where you could efficiently handle data driven applications. I still have doubts however how such local database engine fits in with the total OO setup in .NET. I guess time will tell.

Oh yeah, when it happens I expect John to come up and do his evangalist thing again; this time with a new argument "Since .NET has a local database engine there is no reason anymore to use VFP" .......

>At the project I'm working now I use the same approach, keeping as much as possible static and lookup data locally and use this local tables to do local joins and UI presentation (lightning fast). Only transactions go over the wire.

>I tried also using the embedded FirebirdSQL as local engine, but the extra overhead added by ODBC acces style slowed things down.

>Anyway,regarding NET lack of a local database engine, things change in this area and I don't see that VFP is the one that fill this .NET gap, unfortunately. I mean that already are products for this: CodeBase for NET, TurboDB for NET, VistaDB for NET,Firebird, etc.
>From what I've seen, usually these database engines are small, around 1 M, and some can be compiled to managed code or the database engine is provided as a small dll + the NET provider, without the need for install operations or registry entries.
>
>I believe that, in case of engines packaged in a DLL and the data acces through NET provider, the use of VFP as a local database engine will be much faster (because the overhead of data transfer ADO.NET datasets -> local database engine and back).

>I don't know what to say about engines compiled directly to managed code, as CodeBase.

Since I do not know its implementation, I could not comment either. However, again, more important: Let something become the standard and work from there..

Walter,