>>
>>And when the memo field gets corrupted, as so often happens, you will need a way to retrieve the .PRG recompile it and repopulate the memo field. Why not make it infinitely easier on your self and use individual .PRGs.
>>
>>Another suggestion: use a factory object. This factory will create the final object - I understand instantiation times may be a problem. Accessing a method is slower than a .UDF. The final object will hold a method instead of the .PRG. This object can be based on a class which has the default behavior. Subclasses of this object can have specific behaviors.
>>
>>In that way, you may be able to reduce the total number of .PRGs by reorganizing them into a hierarchy of similar cases.
>
>If you read one of my previous messages in this thread you will see that I was also concerned with memo corruption. So you make a good point for the case of .PRGs.
>
>This is an interesting suggestion for what you call a "factory object". And I found that I can group many of the PRGs into one using parameters. So this will reduce the number of PRGs considerably.
>
>Thank you very much for your helpful suggestions.

Something that I didn't see anyone mention here is the use of a Procedure file (SET PROCEDURE TO ...) and store the name of the procedure in the table, then call with DO (cProcedure). This way will provide a secure way to store the code and a fast way to call it (no memo field). It is similar to having indivual PRG files but the procedures are contained in one PRG file.

Dennis