Thanks for taking the time for all that detail, Mike.

In the end, though, it remains my sense that VFP is better off *within* VS.NET than outside of it.

Cheers,

JimN

>Hi Jim,
>
>OK, first let me start by saying I only listed differences. I didn't try to make any claims one way or the other as far as if the differences themselves were pros or cons.
>
> "It has its own database engine. "
>> can't argue that as a fact, but it does prompt me to ask 'what real good would VB or C++ or C# be if they *couldn't "do data"?
>
>I'm not saying any of these other products can't do data
>
>>Since these others can "do data" through additional components, doesn't this make them 'equivalent' once used to "do data"?
>
>Being able to do data and actually having data aren't the same thing. All of the other products require the use of some external database engine and ADO/XML in order to do data. Again, I'm not trying to make any claims regarding what's better or worse, just pointing out differences.
>
>> And in this case, wouldn't an integrated database engine be a beneficial feature of a product?
>
>Certainly, again, I'm not talking pros & cons, just differences.
>
>"It has techniques for accessing remote data that are unique to Visual FoxPro. "
>
>> Would it not be true that VB and C++ and C# also have their own unique techniques for accessing remote data?
>
>Not really. For the most part you're talking ADO, XML and stored procedure calls which are also viable in VFP. VFP also offers Remote Views and SQL Pass Thru.
>
>"It does not use the common language runtime. "
>
>> That's a MS decision that could be "corrected". And if VFP is just about finished (as has been stated on UT at various times) then wouldn't that be one task that the VFP team could undertake?
>
>The VFP team isn't in charge of the CLR. Because none of the other languages in VS have a database engine the CLR doesn's support, USE, SCAN, REPLACE, etc. "Upgrading" the CLR to support the entire VFP language or creating a precompiler that would flawlessly translate XBASE syntax to make use of ADO/XML would be a huge undertaking. I don't think it's something that could be accomplished within the next year.
>
>"It will continue to make use of COM and COM+ to communicate with external objects instead of the new mechanisms available in VS.NET. "
>
>> Is this a problem... or even a difference - won't the others also continue to make use of COM/COM+?
>
>I wouldn't call it a problem, but it is somewhat of a disadvantage. The others can use COM/COM+ and I imagine that they will in some cases, but all of the dificulties associated with the registry and deployment are supposedly eliminated in VS.NET.
>
>> And again, if VFP is just about finished, wouldn't this be a task that the VFP team could undertake?
>
>No. The CLR is necessary for this stuff. Basically things compiled in the CLR have their own meta data and don't need registry entries and things like that.
>
>"It has its own set of design surfaces that differ from the rest of Visual Studio. "
>
>> I thought that DevCon showed them all getting ever-closer though.
>
>DevCon showed them all being one and the same, except for VFP.
>
>> Maybe by VFP8 VB would be endowed with all of the capabilities it is now missing and they will be the same (IDE-wise).
>
>From this point forward, there is no VB development environment as we know it today. It's all part of the Visual Studio IDE. The only way for VFP to become one and the same is for it to be completely integrated into the VS IDE. Essentially that means throwing out the entire VFP IDE and instead using the VS equivalents (where they exist). Doing so would basically require that VS becomes more like VFP vs. VFP becoming more like VS. There's a ton of language that would have to be supported, the VFP report writer, the DBC, etc.
>
>"Visual FoxPro provides many features that are not supported by the common language runtime. "
>
>> Isn't this essentially the same as your third point above? And isn't the answer basically the same?
>
>No. Basically you can do things in VFP that you cannot do in VB, C or C#. That's not entirely accurate. What I mean is there are VFP commands that act on VFP cursors that we use every day in our applications. Code to accomplish the equivalents is dramatically different in VB, etc.
>
>Markus pointed something out a while ago regarding the CLR that really hits the nail on the head. Take some code like:
>
>

>USE CUSTOMER
>SCAN
>    REPLACE ZipCode WITH ZipPlus4Lookup(Address, City, State, Zip)
>ENDSCAN
>

>
>Without native database access you'd have to do something like:
>

>oCon = CreateObject("ADODB.CONNECTION")
>* Set a bunch of properites that tell the connection where "Customer" is.
>oRS = "SELECT * FROM Customer"
>DO WHILE NOT oRS.EOF
>    oRS.Fields.ZipCode = ZipPlus4Lookup(oRS.Address, oRS.City, oRS.State, oRS.Zip)
>    oRS.MoveNext()
>ENDDO
>

>
>So, how does the compiler figure out where customer is? What about work areas? Let's say ZipPlus4Lookup has a statement in it like SELECT ZipLookup. What does it do with this?
>
>I'm not saying it's impossible, but it certainly isn't trivial and this just scratches the surface. Don't forget VB is in the CLR and the VB programmers are losing backward compatibility with VB6.
>
>"Visual FoxPro 7.0 code will not run in the managed code environment and will most likely outperform VB and C# code written to perform the same functions."
>
>> Again, if VFP is just about finished, aren't there some 9+ months left to do something about this?
>
>Do what, make VFP slower so it matches the performance of VS.NET or put VFP in the CLR
>
>> Finally, virtually all of the businesses that I can think of NEED to "do data". And virtually all of the businesses that I can think of will NEED VS.NET for the 'foundation' of their business applications.
>
>I can't think of a single business that NEEDS VS.NET. They need solutions to business problems and VS.NET is but one potential way to deliver those solutions.
>
>> BUT... countless of the businesses in the world cannot afford the costs of full-blown SQL-SERVER/Oracle/DB2 nor the ancillary costs associated with them and nor do they need ultra security/scalability/etc that they might deliver.
>
>There are a number of low cost alternatives to SQL Server, Oracle and DB2 available with VS.NET. MSDE, MySQL, etc. For that matter VFP 7 will have an OLE DB provider and because of it, VFP data will be very accessible from within VS.NET, but it won't be accessed in the same manner in which VFP applications get at it.