Re^3: Encoding issue after upgrade

Compare the database data bytewise (old versus new). Log each function's input arguments, compare the logs on the old and new systems. Run each function on the old and new system, compare the returned data (should have been covered by tests).

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

Comment on Re^3: Encoding issue after upgrade Download Code

Replies are listed 'Best First'.
Re^4: Encoding issue after upgrade by Bod (Parson) on May 06, 2024 at 23:24 UTC
Compare the database data bytewise (old versus new) Got it! Thank you. kicks self for not noticing sooner The rogue characters are all present in the database. So the problem was introduced during copying the data between database tables. It probably needs to be manually cleaned up as there is more data added since the move...	[reply]
Re^5: Encoding issue after upgrade by cavac (Prior) on May 07, 2024 at 10:04 UTC
It probably needs to be manually cleaned up as there is more data added since the move... I would hazard a guess, that while the copy operation messed up the data, it messed it up in a very specific, methodical way. Probably all the bits of the data are still there (just in the wrong order/encoding) so with a bit of tinkering and math, you could possibly write a script to reverse the damage. If you also have a copy of the old database, you could write a script that specifically updates the lines in the new database with the data from the old one, which would be even easier. PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP	[reply]
Re^5: Encoding issue after upgrade by Anonymous Monk on May 07, 2024 at 22:32 UTC
check if anything changed in the DBD driver you are using. the data itself might not have been changed, just how it's decoded when fetched.	[reply]