>>>>Just want to point out that my code for splitting a procedure file into individual PRGs is now in the Thor Repository. My article about it, including the reasons I don't like procedure files, is here: http://www.tomorrowssolutionsllc.com/Articles/Splitting%20a%20Procedure%20File.PDF
>>>
>>>Having a common utils.prg allows encapsulation, a single place to search for the function you need.
>>>
>>>When trying to find your missing function use Tools -> Code References and search for "FUNCTION myFuncName" and you'll find it quickly ... if you truly don't know where it is.
>>
>>And you can use Code References or GoFish to find it in a PRG, too. Or, since the PRG name is the function name if you use my tool, you can use Finder to find it.
>
>It's a philosophy. I believe in encapsulation. Most of the utility functions we've created over the years are black boxes. We rarely have to go and update them any more, just periodically, so it's not so difficult to find them.
>

If they're black boxes, why would you want them to be used in any way differently than built-in functions? The need to include SET PROC means they're harder to use than built-in.

>What is your position on using stored procedures? They are encapsulated in a single location.

Stored procedures are OOP-like, in that they travel with the data that relies on them. My view is that they should only be used for things that must be enforced at the database level, no matter where the database is used.

Tamar