My guess is that you have an encoding discrepance btween the MySQL data file and your FMP data file.
TidBITS talk recently had a lengthy thread on this very topic. It traced ancient history of the original ASCII characters and their translation to the various flavours of UTF-8. If you can find someone who recognises the way the encoding variants behave with the mangled characters, and how that encoding info is stored in the file, you can hopefully resolve the issue,
Sorry but I'm not that person!.
It could be the encoding / storage settings on the original SQL field... It presumably is set to be an ascii field yet you have used non-ascii characters.
In the word "Whangarer's" is it a foot symbol or a proper curly quote that has been entered?
I believe it is a curly quote.
We did not have this issue before upgrading to FileMaker 12 and the new ODBC driver, so I can't imagine the issue is at the SQL end as they haven't changed anything?
I also haven't changed anything in our FileMaker database, it was a straight upgrade from Filemaker 11 to FileMaker 12.
That is my suspicion also.
I know how to check the collation settings in the MySQL database but I don't know how to check the equilivant on the FileMaker side?
After some more testing I have narrowed the issue down to the ODBC driver.
I was able to get a test windows server set up with a different ODBC driver installed and connecting to the same MySQL database the text looks correct.
Unfortunately we are already using the latest version of the Actual driver, and while the website I got the Windows driver from also has a Mac version, it only supports Mac OS 10.7 and our servers are 10.8 so we are going to have to come up with another solution (most likely we will have to migrate to Windows servers earlier than we had first planned!).
Thanks for the replies!
Bring this to the attention of Jonathan Monroe, from Actual. If it's a bug, I'm sure he will endeavor to correct it. He will be at Devcon if you happen to be attending.