I was going to let this go becuase it seems obvious to me that you have trouble *READING* what I write (maybe you get so ticked so fast that rationality leaves you) but after a little more reading I decided to come back and answer. . .

>>As you know I try to avoid replying to your messages, but here again. . .
>
>Of course, because you know it is likely that I will find the fallacies in your arguments - and unlike most - will be sure to throw them right back in your face. So, if you are replying to my messages - in spite of yourself - I must have brought my A game to the schoolyard today.
>
>Ok, the game is afoot....let us begin...
>
>>You are getting one heck of a lot of mileage out of this "right tool for the >job" statement.
>
>I suppose you are one of those guys who feels that one tool is suitable in all occasions. Perhaps in your case it is. In my case however, I deal with all sorts of applications - each calling for different types of tools. Most of the time, VFP is the tool I use. There are times however, when I do stray and dare to use another tool - because in my estimation - it is the correct course of action to undertake.
>
>Jim, its 1998. One size does not fit all.
>
>
>>Frankly, as far as VB/ACCESS/VFP/FP is concerned, VFP has to 'win' (ie BE THE >RIGHT TOOL) just about always! That's simply because, as many have said quite >frequently, there is virtually nothing in VB or ACCESS that cannot be done >with VFP, *plus* VFP has always had GREAT DB capabilities while VB is only >just now getting them with ADO.
>
>Jim, in case you have not noticed, the latest version of VB is not 3.

- What's this about - did I not mention ADO in my statement. Was it in VB3???

Yes, a lot of people have SAID there is virtually nothing in VB or Access that cannot be done in VFP. However, that says nothing to support that VFP is still the correct tool in all situations. I could easily turn the tables and say that there is almost nothing you can do in VFP that could be done in VB. Don't bit too hard on this is very leading on my part.
>
>Check out the October Journal of Object Oriented Programming. There is an article titled Object Oriented Capabilities in Visual Basic. Two developers had developed a game in Eiffel - a fully OO language. They wanted to see if it could be done in VB. Guess what, they pulled it off and it was much easier than they thought. Oh, in case you were wondering, they made heavy use of inheritance in Eiffel. And yes, they were able to successfully simulate inheritance in VB.
>
>>So, puhlees, stop using that dumb line.
>
>While you have gone to great lengths, you have failed to succesfully attack my premise of using the correct tool for the job. Logic 101 - strengths in one tool do not necessarily equate to weaknesses in another tool. Okay, you want to play that game - VB supports ActiveX controls and ADO to a much larger degree than VFP.

- Yep, and with VFP as mid-tier we can expect VFP to stay just where it is too. And VB just got ADO. Unitl Sep 2 there was none, so yes, VFP was best.

Does that mean that VFP sucks as a tool? Of course. Each tool has its own strengths and weaknesses. If I needed to use a special ActiveX Control that only worked in VB, you can bet I would be using VB as my UI. I suppose you would not - since by your own admition, VFP is always the right tool. In this case, I think I will be the one cashing a check on Friday. You on the other hand, will be picking the lint out of your pockets.
>
>So please Jim, stop using that dumb retort. Smell that....its your argument beginning to go up in flames....
>
>>I also find it ironic that you, in the case you cite elsewhere in this thread, >"deliver what the customer wants" while you will not countenance the prospect >that a VFP customer might loathe and otherwise dismiss any type of (external, >such as SQL Server) SQL.
>
>Selective reading and citing must be one of your specialties Jim. Where have I said that one should force a solution of SQL Server and VB on a customer that wants a VFP based solution?

- Here's where your reading trouble really gets bad. . . I said that I supposed your answer would be such and such, *not* that you said such!

Never. In cases, there are times when on a technical basis, there are times when that approach would be better. At the same time, there are times when SQL Server is pushed - and the customer would do well to use VFP. It all depends if you want the work and cash a check or not. If you can do well with a VFP only repertoire - go for it. One should be open to using other tools - especially if it opens more doors of opportunity.

- MOre reading trouble. . . I said a customer rejects anything of the SQL variety. You would still "push it"? Is that how I'm to read this?

>
>You may not beleive this Jim, but more companies use VB than VFP....
>
>In the end, it is all about providing the customer what he/she wants. Please don't even make the lame attempt that I have, or ever suggested otherwise.
>
>Hear that, that is your argument getting ready to hit the ground......
>
>>I can only guess that your answer is to force him into it or walk away from >the work. After all, **IN THIS CASE** the customer is unenlightened as regards >the benefits of 3-tier and of SQL Server in particular.
>
>No, that would be coming from you. I am all about providing what the customer needs - and having the flexibility to do it. You an your myopic views - being VFP only - would force people to miss out on work. Thats OK, guys like me will be happy cashing those checks.

- reading ??? - The customer *REJECTS* anything to dowith SQL. Get it??
>
>Look, if a guy has to walk away from the work because he cannot provide what the customer needs, thats the developer's problem. Its also the client's problem because he needs to find somebody else.
>
>If you don't like change - you picked the wrong profession.
>
>>In addition, it may be fine for you to learn every language out there, but >most of us are not particularly so inclined. We feel that we have a pretty >darned good language in VFP and we want to keep it that way - to keep it >growing to meet trends and customer demands. To restrict it to a "premier >middle tier" application is a folly, which I have pointed out often enough. >VFP simply stops growing in those areas where developers (and their customers) >need it to. As you no doubt know, it is the UI that most customers see and >base their requirements on what they have witnessed elsewhere. We, VFP >developers, soon will not be able to meet their requests.
>
>Playing the victim now are we? Look Jim, don't set yourself up to speak for everybody else. If you want to speak for yourself - in support of your myopic philosphy - go for it. I am not going to get into the debate of where VFP should or should not go. I have stopped viewing things in a particular langauge. Yes, old habits die hard - since I tend to with use VFP or VB as examples. Right now, I am trying to take a Visual Studio approach to things. Its all about flexibility and using the right tool for the job. I will go down that path.
>
>Jim, you don't have to justify your position to me. I know VFP is a great langauge. Heck, I spent a total of 1 year putting out two editions of a VFP book. That said, don't play this we vs you game with me. It simply does not fly.
>
>If you feel comfortable with your position, great. Lets be sure to talk in two or three years....
>
>
>>VFP was always the right tool for the job (at least when compared with >VB/ACCESS). So please keep that phrase for where it truly is applicable, like >possibly VFP vs C++ for a high-speed cruncher with lots of rendered graphics >or VFP vs APL for mathematical work.
>
>Uh...if an ActiveX Control does not work in VFP - but works in VB, is VFP still the right tool for the job? Not on its own. Perhaps as a middle tier item - with a VB UI. What if you need better support for MTS? VB may be the correct middle tier with a VFP UI. These two examples are bit contrived - but they illustrate the point.
>
>Like most of your views, the two examples you give regarding C++ and APL are also myopic.
>
>Here that Jim... that is your argument crashing to the ground and getting smashed to bits.
>
>Thank you for playing our game. You be sure to visit these parts again. Your lots of fun to have around here....
>
>I know give you this title:
>
>Saint Jim Nelson... Patron Saint of the Myopic and downtrodden VFP Developer.
>
>According to the Vatican, your three miracles to qualify for canonization were:
>
>1. Created the Loaves and Fishes version of VFP. Whatever you needed, it
> automatically came out of the box, obviating the need for anything else.
>
>2. With his team of monks, Saint Jim in 1 night, re-wrote all of the shoddy
> documentation. This lead to miracle number 3.
>
>3. Like Saint Patrick, who rid Ireland of Rats, because Saint Jim Nelson was
> able to re-write all of the docs to Visual Foxpro so quickly and to his
> almighty specifications, all of the evil book authors - who are supposidly
> involved in a consipiracy, were last seen throwning themselves out of the
> nearest building, making this world a better place to live in.

All very cute stuff, Johnny-boy. And the fact that you learned a new word recently really shows through.
You can go on pedaling the MS view of the world. Some of us believe that we should say somethinng when we smell something wrong. You obviously do not. Sycophants are always nice to have around, but they become expendable when things change.

Jim N

PS I definitely will not be responding further on this!