Hi Doug,

I should've been clearer when I mentioned the "vast" majority. I meant the vast majority of developers that DO use third party tools for their database backends (i.e. sql-server, jet, oracle, etc.).

As far as my comparison with Access goes, it wasn't a comparison but a categorization, and I do stand by it (I did think that it might be frowned upon by others, though). I didn't mean to say that access is comparable to VFP in terms of robustness (it is NOT), but just like VFP, Access is a self-contained development tool. Yes, you are right, I'm comparing a Cadillac to an Edsel, but they both belong in the same "class" (pun intended). They are both data-driven thingamajigs (in lieu of better words), they both have reporting capabilities built-in, the both have view designers, and the way projects are presented in both, let's admit it, bear more simmilarities than differences.

Yes, Access is a dog when it comes to serious database processing, but when it comes to categorizing Microsoft tools, access and vfp are siblings more than vb and vfp or vc++ and vfp.




>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