[horde] A fatal error has occurred utf8 is not supported by MySQL
Louis-Philippe Allard
lp.allard.1 at gmail.com
Sun Jun 5 12:32:05 UTC 2022
Quoting Larry Weldon <lweldon at weldoncomputers.com>:
> On 6/3/2022 12:15 PM, Louis-Philippe Allard wrote:
>> Quoting Larry Weldon <lweldon at weldoncomputers.com>:
>>
>>> Hi,
>>>
>>> This post is to document a problem and its' solution. Some months
>>> ago I installed Horde Groupware 5.2.22 on two separate Ubuntu
>>> 20.04 servers. Mysql is the database used. Both installations
>>> worked great for about 6 months.
>>>
>>> Both servers began throwing the exception (subject above) at
>>> slightly different times. The error occurred in the initial
>>> access/login to the server. I didn't notice whether an update
>>> caused it or not.
>>>
>>> Sorting through many different clues from Google searches I found
>>> the following line in conf.php
>>> #$conf['sql']['charset'] = 'utf-8';
>>> $conf['sql']['charset'] = 'utf8mb4';
>>>
>>> Both servers are functioning well again.
>>>
>>> It would be nice to know if an update of mysql or horde was
>>> responsible. It happened on May 9th (2022) and took me awhile to
>>> fix.
>>>
>>> Thanks,
>>>
>>> Larry
>>>
>>> --
>>> Horde mailing list
>>> Frequently Asked Questions: http://horde.org/faq/To unsubscribe,
>>> mail: horde-unsubscribe at lists.horde.org
>>
>> It would be nice to have the full fatal error stack strace to see
>> the actual errors encountered by Horde... For me, on
>> Centos/RHEL/Rocky Linux, I went thru MANY Myql/MariaDB upgrades in
>> the last 10y or so, and never had an issue with Mysql connections.
>>
>> My conf.php shows:
>>
>> $conf['sql']['username'] = '************';
>> $conf['sql']['password'] = '*************';
>> $conf['sql']['hostspec'] = '************';
>> $conf['sql']['port'] = 3306;
>> $conf['sql']['protocol'] = 'tcp';
>> $conf['sql']['database'] = '************';
>> $conf['sql']['charset'] = 'utf-8';
>> $conf['sql']['ssl'] = false;
>> $conf['sql']['splitread'] = false;
>> $conf['sql']['logqueries'] = true;
>> $conf['sql']['phptype'] = 'mysqli';
>> $conf['nosql']['phptype'] = false;
>> $conf['auth']['driver'] = 'sql';
>>
>> I am running 2 Ubuntu based servers (one for a Unifi controller and
>> another for xwiki because it was MUCH easier to get it up and
>> running on ubuntu than Rocky Linux) and both machines are flaky
>> after updates... IMO and experience, the ubuntu ecosystem changes
>> too fast and this can create troubles like the one you
>> described.... Food for thought.
>> Louis-Philippe Allard
>> lp.allard.1 at gmail.com
>> Sent using Horde Groupware on GNU/Linux
>
> Thanks for the reply Louis-Philippe. Setting the conf.php back to
> what it was in my post above reliably gives the error trace in the
> attachment. I also notice your conf.php has mysqli instead of my:
> $conf['sql']['phptype'] = 'mysql';
>
> I was quite surprised to see your charset variable as 'utf-8'
> working as the search results I found always pointed to a problem
> with utf-8 arising many years ago in mysql in which the mysql people
> fixed the problem only by creating the 'utf8mb4' work around.
>
> But I only wanted to document what fixed my problem. I will see what
> is the difference between mysqli and mysql.
> Larry
Larry,
If I recall mysqli is the newer, improved version of the PHP mysql
driver and should be used unless you're missing the PHP libraries for
it.
For the utf8 vs utf8mb4 you are right, it seems thay utf8 is
deprecated and should not be used, but I didnt know that before this
morning! Not sure why everything is working flawlessly on my end and
if I should change that now?
Maybe the newer releases of Mariadb are assuming utf8 is utf8mb4 and
are transparently doing the conversion? I will research a bit on
that.
But for you the question is more why was mariadb not recognizing utf8
at all? When you issue a "show character set" SQL command, what do
you see?
For me I see:
CHARSET DESCRIPTION DEFAULT COLLATION MAXLEN
big5 Big5 Traditional Chinese big5_chinese_ci 2
dec8 DEC West European dec8_swedish_ci 1
cp850 DOS West European cp850_general_ci 1
hp8 HP West European hp8_english_ci 1
koi8r KOI8-R Relcom Russian koi8r_general_ci 1
latin1 cp1252 West European latin1_swedish_ci 1
latin2 ISO 8859-2 Central European latin2_general_ci 1
swe7 7bit Swedish swe7_swedish_ci 1
ascii US ASCII ascii_general_ci 1
ujis EUC-JP Japanese ujis_japanese_ci 3
sjis Shift-JIS Japanese sjis_japanese_ci 2
hebrew ISO 8859-8 Hebrew hebrew_general_ci 1
tis620 TIS620 Thai tis620_thai_ci 1
euckr EUC-KR Korean euckr_korean_ci 2
koi8u KOI8-U Ukrainian koi8u_general_ci 1
gb2312 GB2312 Simplified Chinese gb2312_chinese_ci 2
greek ISO 8859-7 Greek greek_general_ci 1
cp1250 Windows Central European cp1250_general_ci 1
gbk GBK Simplified Chinese gbk_chinese_ci 2
latin5 ISO 8859-9 Turkish latin5_turkish_ci 1
armscii8 ARMSCII-8 Armenian armscii8_general_ci 1
utf8 UTF-8 Unicode utf8_general_ci 3
ucs2 UCS-2 Unicode ucs2_general_ci 2
cp866 DOS Russian cp866_general_ci 1
keybcs2 DOS Kamenicky Czech-Slovak keybcs2_general_ci 1
macce Mac Central European macce_general_ci 1
macroman Mac West European macroman_general_ci 1
cp852 DOS Central European cp852_general_ci 1
latin7 ISO 8859-13 Baltic latin7_general_ci 1
utf8mb4 UTF-8 Unicode utf8mb4_general_ci 4
cp1251 Windows Cyrillic cp1251_general_ci 1
utf16 UTF-16 Unicode utf16_general_ci 4
utf16le UTF-16LE Unicode utf16le_general_ci 4
cp1256 Windows Arabic cp1256_general_ci 1
cp1257 Windows Baltic cp1257_general_ci 1
utf32 UTF-32 Unicode utf32_general_ci 4
binary Binary pseudo charset binary 1
geostd8 GEOSTD8 Georgian geostd8_general_ci 1
cp932 SJIS for Windows Japanese cp932_japanese_ci 2
eucjpms UJIS for Windows Japanese eucjpms_japanese_ci 3
Louis-Philippe Allard
lp.allard.1 at gmail.com
Sent using Horde Groupware on GNU/Linux
More information about the horde
mailing list