One issue I might have to disagree with you on is to use the # of records as the sole deciding factor.

In a corporate environment, your users might already be on SQL. Why would you want to give them a new application environment if they are already used to SQL Server. Such as reporting thru Crystal.

Especially if the data from the new app might eventually need to be mixed in with the existing data for reporting purposes.

PF

>Far be it from me to be argumentative, but that "vast majority" quote was just too good to pass up.
>And I guess I would have to beg to differ. The vast majority of VFP programmers (developers?) do not deal with very large scale database applications which would be suitable for SQL server (and its ilk) but for the run of the mill application which requires data storage in the range of 5000 records to one million records, it just does not make logical sense to saddle your users with the huge expense of licensing SQL server, when you control the distribution of your VFP database with your own distribution license. So the direct answer to using this 'thing' is to avoid the $14,000.00 plus licensing costs for the end user. The other thing I differ with is the comparison to Access, which is like comparing gumby figures to a carefully built Rolls Royce of old.
>YEs, I would like to see VFP incorporate threading models, and a bunch of other 'Big Boy' features, but even now as it is it is no slacker! (gee, and I only own a small amount of MS stock!)
>
>As one with experience of large scale database applications and one who is certifed in SQL Server AND VFP, My own experience shows that the VFP engine is more robust, much faster, and retrieves data without translation and re-formatting, hence faster and less processor intensive. Say what you may about record pointers, ad infinitum, but prove to me that INDEXSEEK, and SEEK are slower than SQL server in finding a record. VFP belongs in Visual Studio for only two reasons that I can think of, one being where else would Microsoft put it to keep it hidden from OFFICE developers, and the other is the relaqtively common development and compiler environment, that is VB and VC++ can handle VFP classes, and vice versa, and OFFICE is soundly bases in VBScripting which is a subset and uncompiled version of VB Remember qbasic and GWbasic? LOL
>
>
>>The vast majority of developers are quite happy with sql-server, which does everything you're mentioning. Why would MS want to reinvent their own product? Then, why would any developer want to use this "thing" as opposed to sql-server?
>>
>>I think that what really needs to happen is that vfp be removed from vstudio. The other two languages in the suite (C++ and VB) are "pure" languages - if you want to add functionality to them you get third party tools (crystal, sql server, etc.). VFP is really more comparable to Access (it's all self-contained) than to VC or VB.
>>
>>Alex