Ok, I'll agree with that statement in general -- however, the onus cannot be on me because I never limited it to a comparison of MSFT tools and VFP -- in fact, I brought Perl into the discussion because I misunderstood it to be a general performance issue among all tools available. Sorry I missed the bit about VFP versus .Net or MSFT pushed tools -- I thought the discussion could include Java, Python, and Ruby, etc...(although 1999 was a scary year for Perl)



>Maybe I didn't understand or explain myself well enough: when I said "32 bit applications (no data)" I actually meant that the best use of 64 bit is in the backend, which VFP can certainly take advantage of with SQl Server. VFP is not limited by being 32-bit because the application itself does not benefit much from 64-bit and would actually require more memory. SQL Server benefits the most because it can actually take advantage of all that memory.
>
>Remember the onus is on you to make me not want to switch from VFP (other than MS marketing and cheerleading).
>
>>Not so. I was replying specifically to your comment:
>
>>32 bit applications (no data) are actually faster than 64 bit or didn't you know that??
>
>>I wrote my response as I did so that it would be clear... Why use VFP as your first choice for speed if there is no data involved?