My issue is with a badly implemented class interface. Odd naming, awkard handling of data, and all around non-standard (even for FoxPro which doesn't have much in the way of standards in the first place) behavior.

I agree that it works and does some things well, but honestly I've never built applications on that funky model of letting the data engine drive my data loading automatically. I simply prefer to build a business layer where code drives the data access and it's all transparently driven through standard procedural code where you can hook in anywhere you want. And if something doesn't work you know exactly where to go and not dig through some arkane error structures. CA is not framework friendly if you're building a generic layer on top that is pluggable.

Not saying that it's no good - just that it doesn't fit the way work and build frameworks :-) And that particular way has worked well for me even across platforms beyond VFP.

+++ Rick ---

>>Sorry I meant CursorAdapter. It's one of the most awkward abstraction APIs I've ever seen for doing data access :-) The functionality it provides is decent but the way code has to interact with it is ugly at best IMHO. I never used it beyond playing with it for that reason.
>>
>>To me the straight forward approach of SQL Passthrough is simply more transparent and allows you full control over the entire data access process...
>
>I take cursoradapter to be an eventhook on SPT. Whatever you do with your alias (requery, update), some events in the CA will fire, and you'll have a chance to either leave them on automatic or intervene. Once it's tamed, it is very useful and can do a lot for you. It's the taming that takes some time and hair pulling.
>
>Now that I'm using one (tamed CA written by someone else who did the groundwork for me :), I'm happy with it. It's like "see ma, no hands!". And I still have the same level of control as with SPT, and in some aspects even better.