That's why I tend to favor rewrites over fixits if the app I'm supposed to fix is fundamentally flawed - or was just never really designed but was just cobbled together. When I did a lot of VFP rescue work, I ran into resistance until I demonstrated that with a framework in place and a revisiting of requirements it was often cheaper and definitely yielded a better result to just do it right.

Sometimes the old app - or code - isn't bad so much as the design is inappropriate and is something one will just have to keep fighting if you don't take a step back and fix it. A bad code module can be refactored, but a bad data design is forever <s>

>Good advice for many areas. I'm currently porting C++ code to C#. Because the C++ code is a work-in-progress, I tried to make the C# code mirror the original code as much as possible (varible names, methods, etc.). But there was one section of code I just didn't understand. Finally I went to the original author, got the info in English, and wrote it the "C# way" in short time. I'm currently testing it.
>
>>When faced with this kind of code which probably "just grew" my first reaction is to ignore the code completely and start out by defining, in English, exactly what I am trying to accomplish. Once I can articulate just what I am trying to accomplish I can start looking at the procedure to see what parts can just be refactored into a user defined function. ( with the appropriate performance caveat - see the suggestions regarding CTE - a way to see it is only evaluated once )
>>
>>Then start building the select, testing performance as you go.
>>
>>And of course check the execution plan as you build each refinement into the select
>>
>>IOW, don't start with attempting to fix what you have - just use it for guidance as you think about the best way to do it right.