See DotNet LINQ for an interesting new development in the .NET languages
The emphasis of data access in DotNet is placed on scalability, distributed applications and web development. There are a large number of features that work well to create these applications. There is however a price to be paid for these features and this design: it is considerably more complex to work with, requires more layers of objects and is slower with large datasets.
While this is a worthwhile price to be paid when the scalability is required this only makes live more complex for applications where scalability isnít an issue due to the limited number of concurrent users. There are far more applications that fit the limited number of users criteria that than are used on a scale that scalability becomes an issue, unfortunately the second group of applications receive far more attention. In the case of the first group of applications the disconnected DotNet design can be more of a hindrance than a help.
One of VFP main selling points in the past has been the ease of working with data, even relatively large amounts. It is relatively easy to create an application that will work with large sets of data and a reasonable number of local users. A large portion of all applications build fits into the category where VFP and its data access strategy are perfect and scalability isnít much of an issue.
For developers creating these types of applications I would like to see an alternative for the standard disconnected DotNet Data Set which works very much like a VFP data session. This container should be compatible with the standard Data Set class so developers can still do everything they could do with the standard Data Set like data binding and returning the object as the return value from a soap call. The difference would be that there is no need for a connection object and a data adapter object to populate the Data Set as the VFPDataSet connects directly to the files on disk. For the same reason the VFPDataSet does not load all the data in memory but uses VFP style data access to get at the data. This approach means that functions like Rlock(), Flock(), CurVal() will work and should be possible for VFP style multi user programming. Commands like USE would need to be turned into a member function so the developer can easily open and close tables.
My vision is:
- Create a Data Set subclass with the following characteristics.
- Uses VFP data natively. Not via Ole Db or ODBC.
- Use a wizard, similar to Visual Studio DotNet, to create a typed Data Set containing the tables and views that the user selects.
- No need to use Connection, Command or Data Adaptor objects.
- The user can programmatically use tables and views.
- When views are used and the required tables arenít open in the dataset these are opened to retrieve the data and closed again, unlike the native VFP behavior. The reason for this change is that the user can serialize the dataset via soap without having to worry about having opened a million record table by opening a view that selects a single customer.
- Data is retrieved from and stored on disk as in VFP and not in memory as in DotNet
- The Data Set can be used for data binding in the same way as the standard DotNet. Other controls should not notice a difference.
- Data sets should be serializable to XML. The XML string can be used to fill another (standard) Data Set. (low priority).
Maurice De Beijer
I disagree that this is needed. We have XML To Cursor() and Cursor To XML() to do exactly this (disconnected data). Plus, we won't need to be retuning VFP objects from SOAP calls (I think this is a bad idea in any situation). -- Mike Helland
I am not talking about the VFP language and what we can and cannot do. What I am trying to describe is a Ado DotNet Data Set container that is used inside if DotNet, so using VBDotNet or C#, and not using the Visual FoxPro language. The FoxPro part of this is the database with the power and speed we are now used to but is missing from the standard Ado DotNet mechanism. Cursor To XML() and XML To Cursor() are only great functions when working with VFP on both sides, when one of the sides is another environment we are back to XML Dom and parsing. However I am talking about creating a much faster way of working with data inside of DotNet and combining the strengths of DotNet with the strengths of VFP, namely the data handling. Maurice De Beijer
Ah, I see. Can't people use the VFP OLEDB provider to access DBCs and DBFs with ADO.NET? -- Mike Helland
Yes They can but in that case Visual FoxPro provides no more power than any other Ole Db provider. What I believe is that the Visual FoxPro way of working with data is much better that the Ado DotNet design for the large majority of the applications. Just imagine displaying a popup list of 10000 articles for a customer to choose from, no problem at all if you use a VFP table and not much of a problem using a server side cursor. However Ado DotNet reads all data into memory, no server side cursors are possible. This design is great for scalability but generates a lot of extra complexity even when it is not needed. What I am proposing gives VbDoNet developers the power FoxPro developers have always enjoyed so much. The same is true for FoxPro developers wanting to work in DotNet. They are not going to get a VFPDotNet so they will need to switch to a new language like VBDotNet, no big deal as far as I am concerned as a language is only a basic tool and they are all pretty similar anyway. The rich Visual FoxPro runtime library gets replaced by the rich DotNet runtime library, no big deal either. The part that has no replacement that even comes close is the Visual FoxPro way of working with databases and that is what I want. -- Maurice De Beijer
Ok, I understand what you're saying now. You can delete my responses if you want -- Mike Helland
I think I will leave it for now as it appears I wasn't quite clear enough about what I meant to say. -- Maurice De Beijer
After all , I don't understand how this so-called disconnected DotNet Data Set accesses VFP data natively ( Not via Ole Db or ODBC ) if you mentioned VBDotNet or C# inside dotNet.
Being quite unfamiliar with dotNEt stil can't imagine that Ado DotNet reads all data into memory. Even it is 10000000 records ? ( I don't mean here that it is supposed to be selected from poplist ) What great about this design then for scalability , seems to be just the simplest approach. --Michael Mitiaguin
My idea is to create a DotNet Data Set subclass that appears to work like a standard Data Set but still uses connected data just like VFP does. And yes if you load a zilion record into a DotNet Data Set it will load them into memory. The physical memory will not be able to handle this but windows will overlay the excess to disk. The design of DotNet means that you are not supposed to load that much data at once, just like it would be a bad idear to open a remove view in FoxPro with a zilion records. I guess we are spoiled by the luxury of not having to worry about the tables size most of the time in FoxPro.
Maurice De Beijer
Isn't it the design of Client - Server in general instead of only DotNet? -- Kurt Grassl
Contributors: Maurice De Beijer
Category DotNet, Category VFP Future
( Topic last updated: 2005.09.14 12:56:35 PM )