>Agreed 100%. SQL Server is really not that hard to learn for a VFP coder. >It's conceptually very similar to the VFP DBC and the SP language is laughably >simple (btw, I keep hearing that SQL Server will eventually use VBA for SPs). >And there is the advantage that MS is scaling SQL up and down: It will get >more and more inexpensive to use it as a server database for VFP -or- VB >applications and it *is* a helluva lot more bulletproof than VFP.


SQL 7 had really broken down a lot - if not most of the barriers that existed before. At the Workshop I gave with Rod in Phoenix, the attendees were amazed at how easy it is to work with SQL 7.

>I think JimN is looking at this the wrong way. Being an experienced developer >he can learn SQL Server rapidly then go forth into the world and compete with >VB/SQL solutions with the advantage of knowing *data*, a skill that is not all >that common in the VB world.

His viewpoint is very myopic. I will leave it at that... As far as VFP ever supplanting VB in a shop - I don't think that will ever happen. VB has too much momentum. And, that is not the goal of Microsoft by the way. It it were - you would see better marketing for VFP.

>As to the whole middle-tier argument, VFP is carving a niche to be the premier >middleware tool insofar as it's data management and string manipulation >capabilities. Does that mean that's all it does? Nope. But it does give VFP >developers one area where there is a clear advantage in using VFP *over* VB. >This does not detract from VFP's traditional roles, it just adds an area where >we can excel in the Visual Studio world.


Those are some strong words you are using - especially the phrase Premier Middleware Tool. VFP has to work well with MTS to be a premier middle-tier solution. I just don't buy into the whole notion that VFP is necessarily the best middle-tier tool you can develop with. In some cases it is. In many other cases it is not.