>Keith..
>
>How are you? At one Devcon, I know you went out with Rod and myself - as well as a few others. I hope all is well with you...

Yeah, that was SoCal about three years ago when we went to
that comedy club in LA. Bob Green went with us in fact.
"I'm Keith and I'm tough!" :-)

>
>With respect to VFP, the big difference between ODBC and OLE-DB resets with whether you want your data rendered as a VFP cursor or an ADO Recordset object. Each has unique strengths and in practice, I use both.

I've heard that using AdoToCursor() and CursorToAdo() are
reletively slow. Is thaat not the case with OLE-DB?

>
>One issue is whenever possible, if you are going to use OLE-DB, make sure you use the OLE-DB Provider for VFP as opposed to the ODBC Driver for VFP which is encompassed by the OLE-DB Provider for ODBC Drivers.
>
>Man... That was a mouthful!

It certainly was. I'm a little unclear though. My understanding
is that the VFP OLE-DB provider (drivers?) would be used in
other apps accessing VFP data or in VFP accessing it's own data
through remote views right?

Is the big deal now that VFP can now access data from an OLE-DB
provider?

>
>The OLE-DB Provider will provide better performance...
>
>In sum, the issue is not whether you should use ODBC vs OLE-DB. IMO, both have utility in VFP. In fact DataClas/VFP (www.redmatrix.com) makes use of both technologies.
>
>The issue is that whenever you use OLE-DB, make sure you use the OLE-DB Provider for VFP.

Based on this last sentence it sounds like there would be a
SQL Server OLE-DB provider for VFP as well as an Access
OLE-DB provider for VFP, etc. As opposed to ODBC where
there would just be a single ODBC driver for SQL Server
that every application would use.

Am I way off base here?

    ...kt