Yup.  That's why I said "With absolutely no disrespect to the author".  This reminded me of the (now 3) times I've had to go through 600 or so tables to find all combinations of a ClientID and LoanNumber to change all of the loan numbers for a given client.  Not only did they NOT use the LoanID that's contained in the loan table but they spelled "ClientID" and LoanNumber each a half dozen different ways, used leading zeros on some and not on other columns, used dashes on some and not other columns, and had 2 different meanings to "ClientID" types of columns and 3 different meanings for "LoanNumber" types of columns.  What should have been a 1 minute change turned into a week's worth of research and tweaking even after I'd written the discovery code.

And, just like the people that wrote your less (whole lot less) than ideal database, it's actually too late to do anything about it (which would actually have some serious performance and DRI benefits, as well) because it would require a total rewrite of all GUI code, Batch Code, and even simple C.R.U.D... all because someone decided to not get someone who knew about databases until they were in the "maintenance and enhancement" phase.  Oddly enough, if they had done it correctly to begin with, they wouldn't need much of such a phase.

At that's why I cringe every time I see scripts that need to do what you've necessarily had to do.  Again, none of my cringing was directed at you.  Your good article/code serves as, yet again, another good example of why treating the database as "just a place to store data" as an "after thought" is absolutely the wrong thing to do.  It's more proof positive of the adage "If you want it real bad... that's the way you'll get it". 😉

Thanks for taking the time to write the article and share your code.