>*prune (the verb)* If you are talking about an enterprise solution that makes use of a WAN, you can't do that.
>
>Ah, I see, so we are not talking about the suitablity of RV's or SP's in the general sense! Instead we are restricting the decision making to just the Enterprise level. Fair enough.
>

I think it's only apllicable for a distributed application. If you are dealing with any local application, then the effort to distribute your application drops by an order of magnitude.

>>And I disagree with there being no significant difference between total costs of both approaches.
>
>"The common steps are" - I imagine hard to define.
>
>If you (or your clients) are spending as much on distribution as you do on testing - then something is amiss.
>
>Ditto ... on making the change ...
>Ditto ... on change control ...
>

It matters not what type of system you are talking about. The real cost of a system is in the design, development and testing. I don't disupte this. How it came up in this conversation, I'm not real clear on, but it is a valid point.

The point being made was the effort needed to maintain a distributed application using SPs versus RVs. I think John (and later myself) pointed out that the ease of making the needed change and the ease of distributing that change to your user base was made much simpler with the use of SPs. A major part of the system is centralized and readily accessible to you the developer.

>Where I work, all changes need to be ok'd after determining the feasability of the change, this is itself sometimes time consuming and expensive. If a change is deemed worth the effort and gets done, then the new code has to go through User Acceptance Testing (UAT). It makes no difference if the change relates to a stored procedure or a beanie-baby!
>

I agree.

>To get a change into UAT, requires the use of a Lotus Notes database form, this has to be approved by a manager in my dept. a senior User or manager from the User's dept. and finally by someone in Change Control. Typically, a day can go by, before the change reaches UAT. Once in UAT, a User is expected to spend many hours performing regression tests, etc. (this btw all costs an awful lot of money). If the User signs off the change as being ok, then a new change request is raised for production. You could argue that since the Change Control staff are responsible for deployment that an element of this is distribution costs. Whatever. The cost of distribution as a percentage of the total cost of a change (in an enterprise environment) is loose change, when compared with all of the other costs.
>
>And if you are up to the task of maintaining an enterprise level system, then there should be no challenge in ensuring an updated DBC makes it into production. It would seem that you are quite confident about undertaking the one task, but not the other! Yes there is a difference in the risks involved, but the difference in costs (of the distribution element) is not worth looking at.

How do you ensure local database version control when you have little or no access to the remote systems? Sure you can login individually into each user's PC that use your system with something like PC Anywhere and do it yourself but that presents its own problems (e.g. making sure each PC has it running in host mode, finding the time and desire to do something as mundane as this *g*).

I don't mean to belittle the process that leads up to distribution. And I didn't mean to imply that the cost of that process outweighs the cost of distribution (I don't think I did). However, as I said that process is not unique. You use that process before final implementation in all cases (at least I hope you do).

But when you do get to the implementation point for simple changes (changes that can be handled with a RV or SP change), you have to go through the same distribution process that happens with major releases. Or you have to make the "patch" available to your users and be prepared to support multiple versions because some will not update their system. If I make the change to the database myself, I have neither of these headaches to contend with. I can devote my time to other pursuits (analyzing, designing and developing the next change request (CR).