Re: Service programs

You need to think in baby steps.
First, stop using subroutines and use subprocedures instead. Oh, I agree
that subroutines have their place and it normally shouldn't be done so
wholesale. But I think it is a good exercise in discipline to just do it
for a month or two. Then you can make "the right decision".
Next, think about putting that subprocedure in it's own service program.
Or in a service program with other "like" subprocedures. For example,
grouping order entry subprocedures into one service program.

Now, think of other things you can do based on this. For example, let's
say you have a GetPrice subprocedure in your service program. It's quite
easy to take SQL and do a CREATE FUNCTION and make your own UDF (User
Defined Function). Then it becomes easy to do stuff like
select itemNumber, CustomerNumber, GetPrice(itemNumber, CustomerNumber)
from OrderDetail

And, when you're comfortable with that you can create a view incorporating
that function.
Create view orderView as (
select itemNumber, CustomerNumber, GetPrice(itemNumber, CustomerNumber) as
DetailPrice
from OrderDetail)
And this hides much of the complexity of your current system from the end
user.

For those developers who fail to see the light of this and will only call
a program I make the subprogram simply bound to the service program and it
calls the subprocedure. Not the other way around.


Rob Berendt