>Doug
>
>VB people are disbelieving that VFP comes with that testmerge facility. I've taken a record of JVP suggesting that it is WW, not VFP, that provides the textmerge. Actually WW would be far less of a player without VFP's textmerge and a canny fellow like Rick Strahl would have had a VB version out ages ago if there were a way. I'm sure RS would agree with that.

I agree somewhat and disagree somewhat. Textmerge can be faked with a function. EVAL() cannot. Rick has stated plainly that he has not written WWWC for VB because of the lack of EVAL().

>I've said it elsewhere: IMHO the single most important feature in VFP in 2000 is textmerge. The rest *can* be done by other tools like VB...

Nope, not EVAL().

>As for SQL: as of SQL Server7, there is no reason not to use it. Until Version 7 it could be quite hard (you could not create a logical [bit] field except in code, for example, nor could you alter null status for an existing field) but now you can. IMHO anybody who can use VFP can set up and manage a SQL Server7 database without much trouble. You can also use the free local variant to experiment, actually if you have a single COM WW app, you can use that free database instead of SQL Server.

This I completely agree with. With the advent of MSDE, the case for VFP data is getting smaller. The application size/ usage level that dbfs are best suited for has narrowed significantly. The strategy of using MSDE until your app needs SQL Server has few downsides. Sure, C/S or n-tier apps cost a little more to develop than monolithic applications, but once you have a framework in place the difference in complexity is minimal, and at least in some cases, debugging is easier using a Server database.

I urge the VFP developers who have not looked into this yet to look into it now. The oft heard excuse is 'I just don't need that kind of database'. Well you never know until you do (and you will), and when that time comes, if you're not already familiar with a server database, then you're not the best man for the job.