>>I prefer PADR() just because it will give me the proper length even if its parameter is shorter. IOW, left("abc", 8) will have a length of 3, but padr("abc",8) will have 8. Saves some looking up the table structures, and saves from some of changes in their structure.
>
>I agree. I think it's a good practice to take maintenance into consideration and not just address the immediate need. Pity the poor maintenance programmer, who often is us <g>.
>
>Your solution might well place the PADR() expression on both fields in each select.
>
>As you note, some modifications, especially making the length of one field greater than the current max length of either, would require more extensive work. But, defining the max length of those fields as a defined constant would minimize the amount of changes needed in expressions like this.

It would be good if we knew which fields would need this sort of zipper (or how would you call "stretchability"), but in the few cases when this was possible to know, it worked great. Simply changing a constant somewhere and recompiling did the trick, because the app started with creating its own tables - and the widths, among other things, were defined there. The only downside to this was that some columns in the reports had to account for this max width, so using a shorter one created some white space.