>>No, DBC on every comp is no-no for me. Like I said I prefer using CAs. That is so more flexible.
>>Also I prefer all executables to reside on local computers and the database should be somewhere else.
>>
>>For client -server:
>>From our experience - you just make setup for your executable (NO DB included)
>>When you need to install DB just send it to IT guys of your client.
>>If they do not have such then make sure you have access to the server where you DB will reside and install it their by yourself.
>
>I have used DBCs on every local and remote PCs for many years and haven't got any problem. The DBCs only holds the connections and remote views. All the remote views point to one and only SQL Server which, by now is located on our central office. And of course the connections' info are created on the run.
>
>I don't see a big improvement on CursorAdapters over remote views besides not using a DBC. If CAs would allow me to use data disconnected, that would be a big improvement, say, connect, get data, disconnect, manipulate data, connect, save manipulated data and then disconnect. Is that possible with CAs? On the contrary, remote views have to be connected from when they are opened until they are closed.

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.