Alex T⚜️  while this *should* work as a "solution in process" to reset the column names, its not imho the most correct way for this element of the software to behave.  Nor is "repair tables" (but that wasn't suggested here.)   my suggest:  una team should be considering coding a price engine- which uses its own database.   sure, it can run sql, that should be fine, but it should run ISOLATED in its own sandbox, and have a seperate DB that does not mix or share or have any injections on or off into or with the main UNa database... as in ZERO relation.  other than the main una db would then rely on the pricing engine, but assuming you code the pricing engine properly thee will be no issue.  

 that will of course require a re-write of all modules that utilize price, BUT...   after looking through the various modules that use price, combination of data types, etc-  "and YES while SQL can handle it," it is a much better design to give SQL less to do and thusly less user overhead (in that all important 'UX/enduser-Wait-Land-type-hell') caused by slow processors, full harddrives, and mobile processors and datagram problems, by writing cleaner more compartmentalized code, these terrible issues we have such problems sleeping because of on occasion, should go away, or not exist,  & & ..  the rest will speak for itself and may even surprise you :-P