John,

>Do you think for one moment the architects involved are going to allow the scenario of VFP performing better or being more stable than web services built in VB or C... I don't think so...

Why not? Do you think they will somehow try to cripple VFP's current capabilities and take away the Web Services that we can already do NOW?
The architects involved don't control Web Services, since it's based on an open spec. It's not a question of what they will allow. :-)

>Let me put it this way..if VFP's data engine where that strategic and that much better, it would find its way into .Net. .Net has a pretty good data engine. It's called SQL Server..< vvbg >... Again, my comments related to VFP's data engine being irrelevant. It was a very specific statement..

And let's see.... what's the Internet licencing fee gonna be for SQL 2000? I believe it's $5,000 PER CPU, and $20,000 per CPU for Enterprise version. I can see that VFP's engine is irrelevant to the MS bean-counters, and can be very relevant to my customers.

Again, it's not all big corporations out there, and as good as SQL Server is, it's not the only answer that makes sense.

>Here are two of your sentences from above:
>
>"I think the most important considerations for Web Services should be performance and stability. It's too early yet to tell what the story will be there."

>That said, how do you know VFP-based web services will be easy to create and maintain. And, how do you know they will "scream" due to the local data engine?

Because they are easy to create and maintain right NOW, and they scream right NOW.

>You couch this conclusion from the standpoint that the other tools will be less easy to maintain? That they will not scream?

Didn't say "easier" or "scream more" than the other tools -- it's too early to tell about that. My point is that VFP likely will remain a very viable and useful option.

>This local data engine advantage that VFP supposedly has, I just don't see it. I cannot reconcile the fact that if it were that good, you would see it perpetuated.

It is that good, and it is being perpetuated. We all know that it's a marketing problem for MS as to how to position VFP, but it still is often the best tool for the job.

>sorry, I just don't see it..... single tier/two-tier C/S apps, VFP is the way to go. Web based/multi-tier apps, there are better tools suited to the task.

Again, Web Services themselves can be served up by VFP solutions as part of distributed, n-tier and web applications in a cost-effective and efficient manner. Not everyone must use SQL Server, but even in those cases a VFP Web Service can be useful.

>Come Devcon time, for those of you that go, you will see something from a vendor that is absolutely going to knock your socks off. Up to that time, you would have bet the ranch and the dog that "it" could not be done.
>
>I am not going to spill the beans on what "it" is just yet. I will tell you what "it" is not. It is not Fox. And one part of what "it" is - DATA

Cool. But let's not hype it up too much. :-) I'll certainly take a look and see how it stacks up.