>>The bottom line was that they needed to become more productive. The choices were: Adding me as a PB/Java programmer or them learning .NET and VFP. While the first choice is obviously the easiest road, it wasn't the best. Fortunately, I think, the best choice was made.

Terry,

>George:
>The killer must have been the VFP COMs (in four days) running processes for PB. PB was big in corporate bench shops a fews years back. I never understood it, but I am glad you were there to guide them through the dark shadows of the last 14 monthswith a britely lighted VFP torch to show the way.

I think what also helped was the fact that the support calls on their end was all about their code, not mine. I developed the test application to help them feret out what the problems where.

What I still can't understand is why, because most of the problems have been data related, they didn't follow the documentation I wrote on the COM object.

>Good job George. When you have time - you need to think about an article for us on this subject. Going against the PB powers to be was quite a feat! Our hats are off to a great Coup de' VFP!

I was in the process of writing up a business case for VFP over PB. The first item was going to be cost. Businesses love the "bottom line". In short, VFP won on all counts. Product costs less, there's less development time because there's less code to write (VFP's richness vs. PB's rather C like Spartaness). Since there's less code, there's less to maintain. Further, since we're working with SQL Server, since VFP can directly manipulate cursor's returned from SQL Server, there're fewer SPs to write on that side to maintain.

I was going to go on with a comparison of large organizations, inclduing the government that use VFP against those using PB. One thing that I think may have helped was that several times I mentioned JFAST/CFAST.