PHPMyAdmin forces to use ut8mb4 as default collation - mysql

Ok, so I've spent the morning trying to change the default collation on my XAMPP setup.
Here's the problem: I'm using Format() in a view, to convert a double into a string
CREATE VIEW `test` AS
SELECT
Format(some_data_table.double_number,0) AS string_result
FROM some_data_table;
When I look at the returned column, its showing as utf8mb4_general_ci.
I've tried all manner of settings in my.ini and phpMyAdmin's config.inc.php
to no avail.
As a last resort, I'm prepared to add the collation parameter to view.
I'd be grateful for any tested solution

Ok - i'm going to post my own answer for anyone else who lands here:
(i had seen this somewhere else, but didn't trust it a t the time because there was no explanation).
When the SQL Format() turns a number into a string, it uses the variable character_set_results.
PMA's Variables Tab was showing this as "utf8" but then on a line below, it was saying (session value) = utf8mb4.
So i was aware that PMA was overriding the server default.
My real problem was that I could find no way to change this override - either by using the [mysqld] skip-character-set-client-handshake setting.. or by editing the php.config.inc file.
Today I had a breakthrough.. I established that if I used the same PMA to connect to and older MySQL server, the problem did not occur.
This suggested to be that PMA was forcing utf8mb4 on newer (capable) servers, but not older ones.
I did a text search of phpmyadmin for the string 'mb4' and found the following code in the class: phpMyAdmin/libraries/DatabaseInterface.class.php
// Skip charsets for Drizzle
if (!PMA_DRIZZLE) {
if (PMA_MYSQL_INT_VERSION > 50503) {
$default_charset = 'utf8mb4';
$default_collation = 'utf8mb4_general_ci';
} else {
$default_charset = 'utf8';
$default_collation = 'utf8_general_ci';
}
the PMA_MYSQL_INT_VERSION > 50503 seems to fit with my theory about older mysql versions, so i've backed up the file and edited the class replacing utf8mb4 with utf8 in this function.
phpMyAdmin is now showing what i want in its variables tab, and the Format() function is now returning what i expect.

(I won't give you a tested solution without a failing test case.)
Here's a possible explanation:
mysql> SELECT FORMAT(2e7, 0);
+----------------+
| FORMAT(2e7, 0) |
+----------------+
| 20,000,000 |
+----------------+
But you are working in a "locale" where the "thousands separator" is ., not ,.
The solution has nothing to do with COLLATION. Instead, look at the arguments to FORMAT().
mysql> SELECT FORMAT(2e7, 0, 'de_DE');
+-------------------------+
| FORMAT(2e7, 0, 'de_DE') |
+-------------------------+
| 20.000.000 |
+-------------------------+
I am guessing that MS Access and MySQL are assuming different "Locales", hence stumbling over the thousands separator, and possibly other differences.
References on Locale:
http://dev.mysql.com/doc/refman/5.7/en/locale-support.html
http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_lc_time_names

Related

Incorrect string value - MySql

I have a problem with MySql.
My version of MYSql is : 5.7.33 - MySQL Community Server (GPL)
I have create a discord Bot in node.js, and i have a mistake when a new user with pseudo like this : legoshi🌌🌧
So i have try to follow this topic : How to fix "Incorrect string value" errors?
So i convert my Database in : utf8mb4_unicode_ci
And my error is still here.
At the begin my database was in utf8 and i have the error too.
code: 'ER_TRUNCATED_WRONG_VALUE_FOR_FIELD',
errno: 1366,
sqlMessage: "Incorrect string value: '\\xF0\\x9F\\x8C\\x8C\\xF0\\x9F...' for column 'user' at row 1",
sqlState: 'HY000',
index: 0,
sql: 'INSERT INTO registre (id, user, autohit, ultimate, platinium, `Date Inscription`) VALUES (210490816542670849, "legoshi🌌🌧", 0, 0, 0, CURRENT_TIMESTAMP())'
}
So i don't no how to change this. I have see a lot of topic and all seems to be fix with utf8mb4_unicode_ci but not in my case.
Thanks for you're help.
In MySQL, there are several places where you can set up a character set:
On the server level
On the database level
On the table level (for each table)
On the field level for all character-based fields
On your connection (telling the server what charset will be used in packets you send to the server)
Basically, server-level, database-level and table-level are just defaults for newly created items: New databases are generated with the server's default. New tables are created with the database's default, new fields are created with the table's default. However, only the field-level charset is what actually counts.
So first, you should make sure that the fields you want to store the data in actually are set up to utf8mb4_unicode_ci. Then, you need to connect to the server using exactly the same charset. Be aware that also the collation should match.
You can find out what character set is in use by issuing the following query:
SHOW VARIABLES LIKE 'character_set_%'
You'll see several variables indicating which default is set for various scopes. Have a look especially to the variables character_set_client and character_set_connection. If the connection does not have the correct character set specified, you need to set it up on connection.
It's a good practice to have all character sets match identically. Mixed values will sooner or later cause trouble.
To check the character set which is set up for the field, have it displayed with the command
SHOW CREATE TABLE registre

What is note-level warning in MySQL?

Okay, I understand what are errors and warnings in the context of MySQL. But what's the need of note-level warning? I have already searched the MySQL documentation but didn't find anything relevant. It would be better if someone could shed some light on the what are they and why they are useful.
mysql> create database if not exists city;
Query OK, 1 row affected, 1 warning (0.00 sec)
mysql> show warnings
-> ;
+-------+------+------------------------------------------------+
| Level | Code | Message |
+-------+------+------------------------------------------------+
| Note | 1007 | Can't create database 'city'; database exists |
+-------+------+------------------------------------------------+
1 row in set (0.00 sec)
I've always considered Note to be like an "FYI": something happened, or didn't, that may be of interest. The closest definition I can find in the docs is:
... events that do not affect the integrity of the reload operation
which is from the sql_notes server variable, one perhaps not often used outside of mysqldump.
Trawling through the MySQL source code, looks like Sql_Condition::SL_NOTE annotates warnings of this level. There are a few, but they are mostly as you'd expect for non-impactful information:
Event already exists
Table already exists
Query '%s' rewritten to '%s' by a query rewrite plugin
Password set
Sadly, I would have expected the code docblock to give a little more information about them, but it doesn't:
class Sql_condition {
public:
/**
Enumeration value describing the severity of the condition.
*/
enum enum_severity_level { SL_NOTE, SL_WARNING, SL_ERROR, SEVERITY_END };
This might warrant a documentation bug report to MySQL team.
Interestingly, MariaDB has this to say:
A note is different to a warning in that it only appears if the sql_notes variable is set to 1 (the default), and is not converted to an error if strict mode is enabled.
My takeaway from that, in Maria and possibly by extension MySQL: notes are warnings, but ones that can be ignored because no data-loss or side-effect is described.

Need to use temporary variable to make REPLACE of SUBSTRING_INDEX work

We're running MySQL 5.5.47 on a number of Debian servers. On some of them, we're seeing the following strange behavior:
mysql> set #TKEY:='ARDARD:fae590c4.ffa2.11e5.a318.0cc47a39aeb4-1460351116';
mysql> select replace(substring_index(substring_index(#TKEY,':',-1),'-',1), '.','-') as guid;
+--------------------------------------+
| guid |
+--------------------------------------+
| fae5a2.1--0cc47a 9ae47a 9aeb4a 9aeb4 |
+--------------------------------------+
This is supposed to extract the middle part of #TKEY (between the : and -) and replace all the periods with hyphens. Where are the spaces coming from? Other parts of the result seem to be jumbled up: 9aeb4 has been duplicated, a2.1 has been shifted left.
This doesn't happen if I assign the substring_index to an intermediate variable.
mysql> set #temp = substring_index(substring_index(#TKEY,':',-1),'-',1);
mysql> select replace(#temp, '.', '-') as guid;
+--------------------------------------+
| guid |
+--------------------------------------+
| fae590c4-ffa2-11e5-a318-0cc47a39aeb4 |
+--------------------------------------+
This only happens on our production servers. I can't reproduce it on our development server or sqlfiddle. I compared all the server variables, and there are no differences that look like they should affect the behavior of string functions (there were initially some differences in character set and collation variables, but I changed the dev server to match the production server and still couldn't replicate the error.
On another production server running MySQL 5.5.41 I get a slightly different wrong result:
mysql> select replace(substring_index(substring_index(#TKEY,':',-1),'-',1), '.','-') as guid;
+--------------------------------------+
| guid |
+--------------------------------------+
| fae590c4-ffa2-11e5-a318-0cc47a 9aeb4 |
+--------------------------------------+
This is correct except that there's a space in place of of the last 3.
Can anyone explain this? Is it just a MySQL bug? I couldn't find anything at bugs.mysql.com.
This appears to be a bug that was fixed in MySQL 5.6.5. There's a somewhat similar bug report regarding LOWER(SUBSTRING_INDEX(...)). It was closed with the comment:
Noted in 5.6.5 changelog.
The result of SUBSTRING_INDEX() could be missing characters when used
as an argument to conversion functions such as LOWER().
I suspect the underlying cause is pointer misuse resulting in buffer overflow and undefined behavior. Hopefully I haven't corrupted any long-lived memory in the server.

TOAD is not displaying unicode characters

i have a MYSQL DB. I am storing the multi lingual characters in a table. below is the sample code.
CREATE TABLE test_multi_lang
(
language_name varchar(500) CHARACTER SET utf8 COLLATE utf8_unicode_ci
);
SET NAMES 'utf8';
insert into test_multi_lang
(language_name )
values
('ตัวอย่าง');
insert into test_multi_lang
(language_name )
values
('नमूना');
SET NAMES 'utf8';
SET character_set_results = 'utf8',
character_set_client = 'utf8',
character_set_connection = 'utf8',
character_set_database = 'utf8',
character_set_server = 'utf8';
select * from test_multi_lang;
When i run the above code in TOAD for MYSQL 7.3.1.290 and select the result set it is displaying as ?????????. but when I run the same code through mysql console it is displaying the unicode characters properly. i changed the properties of my toad as
still i am not getting the result displayed in proper format.
how can i solve this problem ?
Thanks in advance.
After trying different options what worked for me is the following setting in my.ini configuration file.
character_set_server=utf8
I'm using xampp and my.ini is located under c:\xampp\mysql\bin folder
Here's the screenshot
To see your current settings run following command in Toad
SHOW VARIABLES LIKE '%CHARACTER_SET%'
after applying the changes it should look like this:
And this is how data looks after changing the setting.
Please note that you'll have to restart mySQL server as well as Toad for this setting to take effect. This change will not be applied retroactively to existing data. you'll have to recreate the old data.
SHOW CREATE TABLE
You will find that the table (or at least the text column) is not CHARACTER SET utf8. utf8 is required there.
This is a duplicate; read it for the cause and solution.
This is probably a display problem Toad is a non unicode software so we have to do a little setup.
You have to set NLS_LANG in regedit and add Arabic language from the region settings. For guidance you can follow the below steps:-
Windows -> Run -> regedit -> HKEY_LOCAL_MACHINE -> WOW6432Node -> ORACLE -> KEY_(YOUR HOME_ID) -> NS_LANG -> VALUE AMERICAN_AMERICA.AR8MSWIN1256
Control Panel -> Region -> Administrative -> change System Locale... -> select current system language (Arabic).
Restart Toad.
Enjoy & Thanks me later

How to display unicode in MySQL result?

http://www.sqlfiddle.com/#!2/82f65/1
I tried this:
create table x(y varchar(100) character set utf8);
insert into x(y) values('爱');
But the chinese character doesn't appear:
select y from x;
Output:
Y
?
I'm the author of sqlfiddle.com. The problem was that I didn't have my connection string and default database encoding for mysql setup to properly handle UTF8. I have fixed this now, but because the fiddle you posted is still using the obsolete settings, you'll have to see it working here on my slightly-modified version of your fiddle:
http://www.sqlfiddle.com/#!2/e79e8/1
Your link might start working eventually, it just needs to clear out of the running memory and be reset. After no one hits it for a while it should be harvested and then ready to be built back up cleanly. Thanks!
FYI, the changes I had to make to get it to work were found here: http://www.compoundtheory.com/?action=displayPost&ID=421
The relavent bits where adding this to my connection string from java:
useUnicode=true&characterEncoding=UTF-8
And adding this to my create database statement:
create database my_new_database default CHARACTER SET = utf8 default COLLATE = utf8_general_ci;
It is working fine in mysql on my localhost. it may be due to mysql charset or some setting please check it.
If you have to run this query via program like php then
run query before select query
"SET NAMES utf8"
It will be return result properly
thanks
The Chinese character is not displaying in fiddle but in actual mysql database it is working fine. Kindly check your mysql version