>The main advantage of a CA is that is stored in code - not in the DBC, so one can alter it by just pushing new code.
>And the properties are much more easy to maintain.
>
>This days work was: A customer liked a special sorting of an otherwise identical dataset. So I inherit a CA use STUFF to alter the SELECTCMD to change the ORDER BY clause and I'm done. I can go the way over inheritance - or change the code in the instance. Try this with an view. You end up declaring a new one with all the crap to set (bloating the DBC), while for me it's a little code to change and to run.
>If would have done this for a view, it would have required a whole version update to control the change of the database, so it's a minor change to the exe.

Concur on all points.

Last time I had to use views, first thing out there was to separate the views into a database, so any changes to views didn't require locking the whole database with the data, only the one with the views... and that was painful enough. And, BTW, slow on the then networks (20 years ago?). Then I just ran gendbcx and let it create the code for all the views... and would than run that for each instance of the app, so everybody would have a views dbc on his %temp% somewhere. Now that was really fast, in both runtime and deployment and actually a tad faster to design, because we didn't have to go through the clumsy view designers, could make them in code... :).

But on the first next job switched to a framework which did all this for me (VFE, IIRC), and then on the next one and all after we used SPTs for everything, until the adapters came along. Adapter is SPT on steroids and few other drugs combined.