>>>That's what was in that back of my mind. After a nights sleep I've come up with a different approach.
>
>>So, what did you decide to do in the end? I mean, if it ain't classified information, we are all curious!
>
>Well, I haven’t implemented it yet but I think I’ll set a variable to .T. to represent one location/timekeeper and .F. for the other. Probably all of the changes will be to table references that I can change with an IF/ENDIF. I’ll compile two programs and to keep track of that but have it all in one source.
>
>Due to the way it’s set up, all the time cards (a separate app) are held in a single folder and I don’t want to change that. I can limit the people the timekeeper(s) see through the personnel table used. Currently the timekeeper is looking after all the personnel. The additional timekeeper will take a portion of the people, leaving the rest for the current person. Everything else stays the same; cost coding, work orders, union/non-union restrictions, etc….
>
>Rather than keeping two separate prgs doing basically the same thing, I believe having a switch in the program itself will make it easier on me in the future (keeping all the code in one spot.) This dual timekeeper setup is temporary and is only going to last until January 1, 2003 with the department is reunited under a single timekeeper again. As I said originally, this is a long and weird story….

Yes, that makes sense. It pays to reduce the total amount of code, especially duplicate code.

Hilmar.