>>It's you decision. ^.^
>>
>>Views are overall harder to maintain, you always need to alter the DBC. If you don't pack the DBC from time to time they will grow. A change to a CA is running with a simple patch of the exe, while a whatever minor change to a view needs some code that will alter the DBC (It should run just once?). It also fits fine in a n-tier scenario.
>>
>>A view needs a DBC so you have to have one even if you are working on a SQL Server. A CA is independend.
>>
>>Agnes
>
>To be frank, I find the idea of having DBC is good. Sort of a container of tables/views which offers functions that acts across them, Without DBC, a lot of thing will have no place to sit... well with all the advantages offered by DBC I suppose we have to pay a price of maintaining it, that souns reasonable.

Maybe on a single DBC per installation design. I have a design where a Exe serves for multiple databases (just as you would use documents in an editor). Every maintenance has to be done by the exe. So you have to have a mechanism to update the DBC's under some circumstances, to lock the differnet states and so on. Finaly you have to have the view definition in code (to create it) and in each DBC too. I've used to check exes version for the updates. But an update need exclusive acces to the DBC.
Customer doesn't like rapid changing versions. So now I use a CA, do a simple patch and it works on an instance.

Since the CA SELECTCMD is a string you can alter the SQL SELECT at runtime - a view need to be redefined with all its coasts.

But I don't like to crusade. It's just an other POV. A CA has it's own problems and if views fits you it should be right.

Agnes