JohnK,

SNIPPAGE - responses interspersed. . .
>
>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.
>
It is *not* the 'learning' that is a problem, it is the additional COSTS, additional complexities and the loss of VFP's SPEED advantage.
FP/VFP tables *can* be quite "secure" when the segver on which they reside is of excellent quality, carefully managed, powered by UPS, in a secure environment, and with workstation users trained to not simply power off or do other sacriliges which could hurt *any* system.

>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.
>
Sure, I could *easily* do that, and I would have far less grief in places like this too! But as I said earlier, the added cost and complexities of SQL Server or any comparative product simply make this a far less palatable option to the VAST MAJORITY of potential clients - clients of the kind, by the way, which I would find far more fulfilling in serving than some giant corp which might just as easily toss *my* product quickly in favour of some other 'soup du jour'.

>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.
>
Data Management?. . . gimme a break! What is *actually* doing the real data management in a three tier environment? Sure, the mid-tier permits or rejects data from 'entering' the database, but what actually puts the data in place and retrieves it again when needed - *NOT* the middle tier. So what has happened to VFP's SPEED advantage in such a case? It has disappeared, that's what!
String manipulation? Woweee!!! That sure is an advertisement for VFP! VFP does fast stringing! WOW!!! And why would string manipulation even be needed in a middle tier *if* the data and form fields were treated as fields in the first place. And, by the way, I see that VB6 has several new string functions which are aimed at speed and flexibility improvements over their predecessors.

John, you are doing an admirable job of 'defending' MS' strategy of VFP as 'premier middle tier', but I'm afraid it seems to be coming from your heart rather than from your head!

With "middle tier" VFP loses the *only* REAL advantages it has, especially since a good argument can be made that OOP is far less relevant in a middle tier than it is in a front end.

We would be far better off, especially given the superficiality of the "integration of VFP into VS 6", for MS and the VFP team to get out of the VS dream and to, instead, go back to serving the small to medium business and its capability to deliver the WHOLE SOLUTION!

Cheers,

Jim N