I was under the impression that a tool like Whidbey, made by developers and for developers, would default to using the best Microsoft ISAM store available in the developer's toolkit. Instead, the best office worker's data tool takes precedence. We all know that the DBC smokes the MDB in "every" way measurable, and we also know that the VFP8 OLEDB provider is available for download.

While it might not be reasonable to expect deskside users to grab the OLEDB provider for manipulating local data, I would think the opposite is true for those of us on the back end writing solutions.

A Visual Studio .NET install currently takes a significant time to install; adding the VFP OLEDB provider would be negligible in terms of this time, but it would (1) give developers a better data store than they're used to in the MDB, and (2) give more visibility to an excellent ISAM file format and tool (VFP8) in general.

I agree that more developers have MDBs than DBCs, but I am sure that would change if the Visual Studio .NET team did anything about it.




...um, I meant "noise"... ;)




>>I was just looking through the latest issue of Visual Studio Magazine, and there is an article on Whidbey ASP.NET features. One of the new features is automated membership/security management in VS.NET; a tool automatically appears to create a database called ASPNetDB.mdb is made to hold credential and personalization info, with the expectation that the database would be upsized to MsSql when needs grow.
>>
>>The fact that a Jet database was used instead of a VFP one makes me a little sick. I find it hard to believe that in 2004, the "new technology" Whidbey team would use an MDB when the DBC has so many advantages as an ISAM store.
>>
>>I hope someone at the VFP group can make some nose about this.
>
>I do not see this as a problem or an issue. MDBs are used many times more than DBFs, and far more developers/users have Access on their machine than VFP since it is included in Office. The DBC technology is 10 years old, it appears in VFP 3.0, about the same time MDBs arrived in Access 1.0. DBFs are just not a common example for remote data connection when referring to things outside of VFP, mainly due to common usage. I just don't see any benefit of making any noise (or nose) about this since it is really not an issue. You just aren't going to see VFP listed in every case it could be, especially in comparison to Access which has such a far higher usage from a general and simple example point of view.