If the DBC (and its views) are stored on a central server then no distribution is required. If not, then it is just as easy to automate the distribution of an updated DBC (with its remote views) as it is to automatically distribute updated stored procedures. This whole argument relies on the cost of distribution being one of the major aspects (in determining whether RV's are more suitable than SP's) - in my opinion this is a fallacy.

There is no significant difference in costs, especially if the cost of distribution is viewed from the perspective of total cost of modifying a system. i.e. including the cost of making the change, testing it, passing it through the proper change control channels, etc. etc.

>Jeff,
>The point being that you now have to distribute "something" to the end users. Whether that something is a new DBC or program that creates/modifies the RV is really superfluous in this case. It is the act of distribution itself that John pointed out in this example. Your example didn't alleviate that burden.
>
>>>With a RV, I need to modify the view to reflect the new order. I then need to distribute the RV. There are at least two steps. And if there is a costly aspect to the development game, it lies in software distribution.
>>>
>>>With a stored procuedure, I need to modify the procedure. There is nothing to distribute manually. I can make use of replication to automate the process of distibuting the change for me.
>>>
>>
>>John,
>>
>>I agree that stored procedures are a beautiful thing, especially in terms of performance, data integrity etc. and are a very powerful tool for a database developer.
>>
>>I just thought I'd point out a scenario where using RV's would mean less modification if the user wishes to change the sort/filter/fieldlist criteria in the app than a stored procedure (which would require the modification of the actual SP on the back-end).
>>
>>You could have a dynamically constructed RV (it is, after all, an SQL Statement) that builds the SQL statement and then makes the call to CREATE SQL VIEW REMOTE blah blah AS based on the criteria that the user enters. This method does not require any changing of code on the client and I found it quite effective for the query tool-generated picklists in an app I previously worked on.
>>
>>Regards,
>>
>>-JT

censored.