>I haven't tested this, but you could try
>SET PROCEDURE TO ('procdir\proc1','procdir\proc2')
>or
>SET PROCEDURE TO ('procdir\proc1'),('procdir\proc2')
>
Since I already had two alternatives that worked, I hadn't considered this one.

But when you and others posted this method I tested it and got strange results. The actual line of code was

SET PROCEDURE TO ('Progs\Data_Env_MySQL','Progs\Data_Env')

Both files were now included in the project. However, when building the project I received a new error

Program c:\apps\jobschtest\progs\insertjobs.prg has the following errors:
Program DATA_ENV_MYSQL' - Undefined

and when running the program got File 'data_env_mysql'.prg' does not exist

Thanks for your effort but no need to waste any more time on this. I have several ways of getting it to work correctly and was merely curious if there were any other places where similar problems might crop up.


>>The code that I have inherited is full of things like
>>
>>USE myTable ALIAS myAlias
>>
>>and then code such as
>>
>>SELECT 'myAlias' ---- rather than SELECT myAlias
>>REPLACE myField WITH myValue IN 'myAlias'
>>etc.
>>
>>This doesn't seem to cause any problems, but I did find a problem with a similar construct
>>
>>SET PROCEDURE TO 'procdir\proc1','procdir\proc2'
>>
>>When the project builder came across this line it only pulled proc1 into the project while
>>
>>SET PROCEDURE TO 'procdir\proc1'
>>SET PROCEDURE TO 'procdir\proc2' ADDITIVE
>>
>>and
>>
>>SET PROCEDURE TO procdir\proc1,procdir\proc2
>>
>>got both of them
>>
>>Are there any reasons to use strings (maybe it made it more clear to him) and does anybody know of any other gotchas from using them?
>>
>>Thanks......Rich