Hey Mike,

Agreed. But... <g>

I'm using it as a way to automatically create an upgrade program from GenDBC output. I have one text file that contains view change functions, which is tacked onto the usual functions from the GenDBC output. Unfortunately, the changed functions already exists in the upgrade program and we don't have time to write a cleaner approach. I will have the duplicate funtion names until this project is released, and then we can take some time to refine it to be used on an ongoing basis. Not perfect, but it seems to work for us right now.


>Hi Mark
>
>I really believe one has to have a set of reasons to support a decision, but it it easy to forget them sometimes, especially when a general rule will suffice.
>
>I make it a general rule to not have function / procedure libraries.
>
>I make each function it's own little .PRG. That way there could only even be two if I put them in different folders, which I would consider a mistake. ;)
>
>>>Pretend this is theoretical... <g>
>>>
>>>I have two exact-named functions in a PRG. A call at the top of the program will run the 2nd one, not the first, which I thought would be the logical choice. Anyone know why? Is this always the case?
>>
>>Yes, that is exactly what is supposed to happen. Been that way for as long as I can remember.