<< VFP can use ADO just like any other tool can use ADO.

Not entirely. In VB, you can take advantage of default properties. For example, the Fields Collection is the default property of a recordset. And further, the Value Property is the default property of a Field Object. So, in VB, I could do this:


x = oRs("customername")

In VFP, I have to be very explcit:

x = oRs.Field("customername").Value


Second, in VB, I can natively bind to ADO events. Yes, I can do this in VFP via VFPCOM. It is a bit of a pain, having to rely on an ancillary DLL to handle this basic functionality. I have also found VFPCOM to not be as reliable as VB's event binding capabilities. In other words, there are times here and there where VFPCOM does not respond to the event.

Third, methods like GetChunk() behave differently in VFP. IN VB, you get the text directly. In VFP, you get the ASCII code. You need to use CHR() to get the actual data.

It is issues like these that make me throw my arms up in the air and ask the question - "Why Bother???"