>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.
Yes it's awkward and we're still discovering in what weird way some things are done, and the names are counterintuitive (why is .cursorfill closing and opening the cursor?). The sql connection settings (batch update count and other such settings) don't work exactly the same as they do for SPT, and before you get it to work there's always one more setting you got wrong etc etc. It takes some learning, "it's technology" - which means it isn't just working at all times, you have to know which buttons to press.
I've seen it done right - the taming that I mentioned, where a friend had more patience than I had - and it, of course, still needs a business layer on top of itself. But that layer only needs to do something like lret=handler.save("alias"), which then takes care of what happened after the last tableupdate() and which drives the adapter.
But like you said years ago, it may be good if you're building a data handling from scratch (which was the case at hand); if you want to plug it into an existing framework, you got some double work at hand. On this project, the data handling was not as good as we wanted, and the CA approach solved our problems. This meant writing some stuff from scratch and cutting out lots of old code, but now that it's done it's running smoothly.