mySQL 8 destroyes umlaute

[Rick Harrison]

Hi Tiemo,

Could you use a substitution table as a work around patch?

Rick

> On Jul 8, 2021, at 8:45 AM, Tiemo via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Thank you Matthias,
> 
> because it is an existing db and years old LC programs in different versions out at the customers, I can't modify my old LC programs out there.
> 
> I now have read that uft8 gets deprecated in mySQL 8 at some time, so that all new and migrated mySQL 8 databases gets by default uft8mb4 (4 byte chars), which LiveCode obviously doesn't like and can't display anymore the umlaute of my existing db. Perhaps everything would work with LC, when creating a new db and storing the data from the beginning in utf8mb4, but that’s not my use case. My live db has as the server character set "latin1" and as the db character set "utf8", which were both switched to utf8mb4 on mySQL 8.
> 
> Now I am looking for a solution either in the PHPs, which are called from LC and connect to the db, or changing the db itself.
> Overwriting the charset in the PHP by: header ( 'Content-Type: text/html; Charset=latin1' ); doesn't affect the output to LiveCode at all, the umlaute stay corrupted. It seems that the settings of the db have priority.
> 
> I have read that you can alter the charset of a database and/or tables (ALTER TABLE tablename CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;) . I am not good in handling databases, so I am not sure yet
> - if this changes just the default value for new db entries or if that changes also the existing db content
> - even if this would work, this wouldn't be a long lasting solution, because uft8 gets deprecated in future and I need again another solution.
> 
> Anybody out here who is good in working with databases / mysql and has any idea how to repair this situation?
> 
> Thanks
> Tiemo