>Sooo...in the right situation, VFP is best used, if at all, with other development tools. But there are cases, often mis-identified, where a single solution is preferable and Fox covers enough bases (front end, middleware, backend) to be that single solution *where appropriate*.

Yes, I would agree with this...

>As to EXE size, please convince me that a VB app of moderate size talking to SQL Server using alphabet soup (ADO,DAO,RDS,whatever) running on a P75 with 16MB of RAM will outperform VFP talking to....err...VFP.

Once again, the context of our discussion of SQL/Server data. Native access will usually be faster. I hessitate to say always<g>. If you are going against VFP data - most of the time - you would be better off using 100% VFP. But, that is not what we where talking about here<s>.

>VFP is superior to VB in RAD.

Not when it comes to full compliance with ActiveX controls. And, not when it comes to making use of ActiveX Data Binding and ADO.

>>VFP is superior to VB as an object-oriented development tool where business rules can be classed and ActiveX controls can be subclassed or wrappered.

Be careful here as you are mixing and matching things. It is important to disguingish things between business objects and the UI. When it comes to OOP - don't even bother to include VB - at least not yet<g>. VB is not OO - it is object based. Until it becomes OO - and more specifically - adopts inheritiance
- it is an irrelevant comparsion.

When you mention wrapping ActiveX controls - you are talking UI - which may be or may not be an advantage. For example, if my UI is sluggish - I could care less about the OOP abilities to subclass ActiveX controls. Also, if I need an ActiveX control - and it bombs out in VFP - but works fine in VB - I might be making the change anyway<g>. Hey - we are'nt even talking about C/S here are we??<g>.

VFP is a far, far superior in small to moderate sized systems that *do not* require a c/s architecture.

I agree with you completely here...

>
>Also, as to ADO....I LIKE ADO! I have used it in a few VB projects and I look forward to it being in Tahoe.

Why wait? You can use it in 5.0.


>
>>3x the cost and 10x the speed? Are your numbers correct here?
>
>My numbers are sadly correct...see another one of my posts in this thread for a concrete example.

10x slower? There is another problem lurking underneath the surface. Either a tuning issue with SQL Server or bad code somewhere else. All things being equal - no way this is right.


>I do not disagree....but in a non-client/server project, are you seriously going to tell me that the JET database engine talking to VB is superior? In a client/server environent I do not disagree with you at all. SQL Server is my back-end of choice for C/S.

When did I mention Jet?? Jet is a piece of crap. Once again, the context of my argument is framed around SQL/Server.


>As to relevency to Ross's post...you know, you're right. He is forced into the situation and, as he describes it, he probably should go VB. I guess I lost the context and was annoyed that you were going down the "VB is God" garden path. Say what you will about Fox people, but we generally tend to understand things better. I have known far too many VB "developers" who don't know what a foreign key is, for example or put code on the client side that belongs in middleware or a stored procedure because they didn't understand 2- 3-tier c/s architecture.

Most VB developers don't know data from a hole in the ground. That is a big advantage VFP developers have. And, please remember - I am a Fox person too<g>.

>
>>The VFP developers who sell people on 100% VFP solutions - because it is what he/she knows - is just as guilty as the consultant who preaches VB and SQL/Server 100% of the time because that is what he/she knows.>
>
>Sad, isn't it? But you find that attitude all over the place, not just in VFP.
>
>
>I agree 100% with the statement that SQL Server devices beat out VFP databases...but only where the scale of the project demands a standalone database,ie, a c/s environment. BTW, have you looked at SQL ver 7.0? It is *sweet*.

The fact that you can use SQL 7 in Win95/98. Can you say good-bye Jet!!?? Yes, it is sweet. Row level locking is nice too!!<g>. If I am not mistaken, stored procs can be coded in VBA as well.

>No kidding John...but neither is it a VB ONLY world. In my experience, you have a heck of a lot more VB developers thinking it's a VB only world than VFP people thinking that way...IMHO

I think you may mistaken here. I find VB developers much more receptive to being a part in a bigger picture than VFP developers are. Look at your response to me. Your defense was to continually hammer away at how how well VFP does non C/S applications. You completely by-passed the premise - that the application was C/S.