>Bob,
>
>I don't understand how the VFP DB engine gets any play at all in the mid-tier. So the fast db engine, which I would agree is a requirement, would be the much slower SQL Server or equivalent.
>

Well... the product I am working on, one of our goals is to deplay a '3-tier' version that uses local files. Combining the SPEED of VFP database engine and the security of MTS, we are going to eliminate the need to have SQL... which alot of our 16-bit/.DBF file clients are afraid of, and don't think they are ready for, or even need to move to.

>SUPER FAST string manipulation - mewthinks you overstate the case just a bit. Am I really going to keep *any* product just becuase it has "super fast string manipulation"??? I think not. And who's to say that VB's new string functions aren't just as fast (especially *if* that chestnut regarding "integration" of VS products has any truth at all to it - maybe the code is the same in both, with only the names changed to protect the innocent.
>

Ever hear of PERL? It main claim to fame is EXTENSIVE string handling flexibility and speed. It has been 'extended' to be able to read and write to databases. Where VFP is designed from the beginning to manipulate data, now we are getting the STRING speed... I tell you what, I have worked with PERL, and if I have a choice between PERL and VFP, I will choose VFP in a heart beat.

The language is much easier to work with, as we all know, the data handling is simple yet fast and powerfull.

BOb