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

Larry Miller
MCSD
LWMiller3@verizon.net

Accumulate learning by study, understand what you learn by questioning. -- Mingjiao