Bob,

That's truly very good, but do keep in mind that you are disrespecting the stated MS design objective - to make VFP a 'premier middle tier' component!

Let me also assume that your 3 tiers are to be (at least) VFP in #2 and #3. Isn't it a real pity that you have to rely on string functions to pass/parse DATA between the tiers??? Wouldn't we all be far better off if the VFP team had spent some time making it so that recordsets could be passed as needed????

Finally, your statement '... 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.' can include a whole lot more small/mid-sized businesses (not only 16--bit folk) and it is THIS market - the BIGGEST by far) which now has really *no* MS product targeted at it and which is where VFP should be aimed.

No, by the way, PERL is one of many which has escaped my clutches. But I can tell you that *I* would not go into a product just because it was great with strings. I'd look for a little more than that!

Cheers,

Jim N


>>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