Quantcast
Channel: MySQL Forums - Character Sets, Collation, Unicode
Viewing all 294 articles
Browse latest View live

Best collation to use for ancient languages (no replies)

$
0
0
Specifically, I'm looking to store some of the ancient languages of the Bible into a database (Hebrew, Aramaic & Greek). Would utf8_unicode_ci be the best one? Also, would be there any character changes?

Thanks,
Tim

utf-8 problem (2 replies)

$
0
0
Hello!
Got a one problem with utf-8. My php is set to utf-8 and my sql database is set on utf-8 but i get some strange characters in database when I insert data. I try to insert č,ć,ž,š,đ, character that in my language. Here on picture one is that characters:
http://www.fer-projekt.com/images/Untitled-1.jpg
On picture two is my database setting!
http://www.fer-projekt.com/images/Untitled-2.jpg
When i call from my data base back to on php page it is normal.
So any help will be helpfull!

Inconsistent behaviour with collations (1 reply)

$
0
0
Hi all,
I've been trying to track down an issue with a stored procedure failing to successfully compare the index of a table with that of it's database.

I've noticed that with all the databases that have failed to work with this stored procedure (live, and at customer sites) have the collation set of both the database and it's tables explicitly defined with a collation of utf8_unicode_ci

The ones that don't have any issue, have no collation set defined, and seem to have an implicit collation of utf8_general_ci

In my connection and collation settings, it is reporting correctly that the default collation is utf8_unicode_ci

the error returned by the stored procedure is:
ERROR 1267 (HY000): Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '='

PROCEDURE quentin_v3.dropIndex(
  IN tblName VARCHAR(64),
  IN ndxName VARCHAR(64))
  DETERMINISTIC
  MODIFIES SQL DATA
BEGIN

  DECLARE IndexColumnCount INT;
  DECLARE SQLStatement VARCHAR(256);
  DECLARE dbName VARCHAR(64);
  SET dbName = 'quentin_v3';

  
  SELECT count(1)
INTO
  IndexColumnCount
FROM
  information_schema.statistics
WHERE
  table_schema = dbName
  AND table_name = convert(tblName USING utf8) COLLATE utf8_general_ci
  AND index_name = convert(ndxName USING utf8) COLLATE utf8_general_ci;

  IF IndexColumnCount > 0 THEN
    SET SQLStatement = CONCAT('ALTER TABLE `',dbName,'`.`',tblName,'` DROP INDEX`',ndxName,'`');
    SET @SQLStmt = SQLStatement;
    PREPARE s FROM @SQLStmt;
    EXECUTE s;
    DEALLOCATE PREPARE s;
  END IF;

END

If I explicitly define the collation for the table schema = dbName comparison, it will succeed for the 'bad' databases, but I'm not sure whether that will be the correct set.

Any ideas?

character_set and collation in new server (1 reply)

$
0
0
Hello, I have to migrate the data from my old server with MYSQl 4.1.12 to my new one with MYSQl 5.1.49-3. I saw the character_set and collation in the two servers and they are different, like this:

VER 4.1.12 (old Server)

+--------------------------+--------+
| Variable_name | Value |
+--------------------------+--------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | latin1 |
| character_set_results | utf8 |
| character_set_server | latin1 |
| character_set_system | utf8 |
+--------------------------+--------+
+----------------------+-------------------+
| Variable_name | Value |
+----------------------+-------------------+
| collation_connection | utf8_general_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
+----------------------+-------------------+

VER 5.1.49-3 (new Server)

+--------------------------+--------+
| Variable_name | Value |
+--------------------------+--------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
+--------------------------+--------+

+----------------------+-------------------+
| Variable_name | Value |
+----------------------+-------------------+
| collation_connection | latin1_swedish_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
+----------------------+-------------------+

So, until I restore the databases I have to update the character_set and collation in the new server so it look the same? or I have to live like that and restore the backup? I would have any problem then with the information stored in DB?.

Thanks.

1267 Illegal mix of collations on a date field in MySQL (2 replies)

$
0
0
Dear mysql-users and -developers

we came across a strange behaviour of mysql with collations on a DATE-Field.

I postet a structured form of this question in my developer blog: http://blog.sky-bizz.com/2011/05/29/1267-illegal-mix-of-collations-on-a-date-field-in-mysql/.


In the following example there is a table with existing records. After altering the table and appending a DATE-Field, this field is NOT writeable in already existing records. The following error message occurs on every write to the field:

1267 Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (latin1_general_ci,IMPLICIT) for operation ’=’



The connection is utf8, the Table was created with utf8 (except the ENUM-Fields), indeed the whole database was created with utf8.

In Detail:

This is the table (i renamed the table for security purposes):

CREATE TABLE `test1` (
`id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
`user_id` INT(10) UNSIGNED NOT NULL,
`location_id` BIGINT(20) UNSIGNED DEFAULT NULL,
`for_time` datetime NOT NULL,
`value` DECIMAL(5,1) UNSIGNED NOT NULL,
`unit` enum('mg_dl','mmol_l') CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL,
`value_mgdl` DECIMAL(7,3) NOT NULL DEFAULT '0.000',
`value_mmoll` DECIMAL(7,3) NOT NULL DEFAULT '0.000',
`source` enum('import','test','user','support') CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT 'user',
`comment` VARCHAR(255) NOT NULL,
`created` datetime NOT NULL,
`updated` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `user_id` (`user_id`),
KEY `fk_copd_location_id` (`location_id`),
KEY `for_time` (`for_time`),
KEY `value` (`value`,`unit`),
KEY `value_mgdl` (`value_mgdl`),
KEY `value_mmoll` (`value_mmoll`),
KEY `source` (`source`),
CONSTRAINT `fk_test1_user_id` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=utf8;


SHOW TABLE STATUS like 'bloodsugar':

Name Engine Version Row_format Rows Avg_row_length Data_length Max_data_length Index_length Data_free Auto_increment Create_time Update_time Check_time Collation Checksum Create_options Comment
bloodsugar InnoDB 10 Compact 8 2048 16384 0 114688 611319808 14 2011-05-29 20:28:54 NULL NULL utf8_general_ci NULL


mysql> show variables like '%colla%';
+----------------------+-----------------+
| Variable_name | Value |
+----------------------+-----------------+
| collation_connection | utf8_general_ci |
| collation_database | utf8_general_ci |
| collation_server | utf8_general_ci |
+----------------------+-----------------+
3 rows in set (0.00 sec)
This table contains some records, and has an overhead of 500 MB (i deleted a lot of records some days ago).

Then i entered the following statement:

ALTER TABLE `test1` ADD `test` DATE NULL DEFAULT NULL ;
Everything works fine right now.

But each of the following statements gives the error described above:

UPDATE test1 SET test=NULL;
or

UPDATE test1 SET test=DATE(for_time);
or

UPDATE test1 SET test='2011-01-01';
and so on….

Result:

1267 Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (latin1_general_ci,IMPLICIT) for operation ’=’

Setting up a new table with all the steps described above works fine and no error will occure.

But altering the existing table gives this annoying error.
My main Problem is: on the production database there are a lot of records collected in the last 6 months. So i am looking for the underlying cause for such an error.

The MySQL-Version is “Ver 14.14 Distrib 5.1.56″ running an Debian Lenny 64bit.

Can anyone give me some hints or explain this issue?

Thanks in advance!

Database migration failing. (no replies)

$
0
0
Apologies for the length of this post, but I suspect I don’t quite know of there is a problem here.

I’m VERY new to mysql, so forgive me if the question seems trivial.

I’m taking over a project which is to migrate a bunch of mysql databases from one server to another. The project has already started, and it looks like the process is also upgrading the version, going from “Source distribution 5.1.25-rc “ to “MySQL Community Server (GPL) 5.5.8”.

The method that was going to be used to get the databases across was by using mysqldump. This appears to work apart from one. During the import of one database, there is an error message of “ERROR 1253 (42000) at line 2055: COLLATION 'utf8_general_ci' is not valid for CHARACTER SET 'latin1'”.

Looking at the results it looks like the target database has a lot less tables in it than the source database.

So I did a bit of poking around in the source database. It looks like there are three tables that are using this “'utf8_general_ci'” clause, and each of those tables has a view hanging off it.

I’m suspecting that it is trying to import the tables in alphabetic order, as from the target database, it looks like as soon as it hit’s the first table that uses 'utf8_general_ci', I think it aborts the process, as no further tables appear alphabetically in the target database after that point.

So, to try and prove a point that it was those three tables that were causing the issue, I edited the sql file that came out of the mysqldump process, and removed the three offending tables from the import. Performed the import process again and the target database now has six objects fewer than the source, which is what I expected, as there were three suspect tables, and each had a view hanging off it.

So……..back to the source database, and if I try to do a describe of the table structure or “select count(*)” from any of the three tables, I get the same error as above.

I don’t think there’s anything worthwhile in these tables, as I would have thought if I can’t select from them like that, they are useless. Or have I misread what has happened?

My theory would be to drop the three offending tables and views, and I’m almost certain that I’ll get a clean migration. My problem is that I have no backout of this.

The author of the application concerned, no longer works for us, so I cannot refer to them, and I can find no system documentation. Not good, and something I will get someone to address in the future.

So in short, am I right in my assumption that these three tables are garbage and unusuable, or have I misread the situation?

Many thanks,

Martin.

Vietnamese character matching with %LIKE% (no replies)

$
0
0
I have run into an extremely frustrating feature, for some reason a query involving select LIKE `%D%` will not match `Đ`.
All other characters that are like this do match, however. `%n%` matches `ñ`, `%o%` matches `ồ`, but if I am searching for

`%Dong Nai%` I will not get `Đồng Nai`.

Is this a MySQL feature or something hard coded into Unicode?

Converting latin1 to UTF-8 without downtime via replication? (no replies)

$
0
0
We're trying to convert a large-ish mysql 5.0 DB from a latin1 character set to UTF-8. We've used the JDBC driver and UseOldUFT8Behavior to get utf8 data into the master's latin1 system, up until now. We want to end this.

Our first thought was to stop replication on one of our slaves, convert the data in the slave to UTF8, then rotate to master after the slave catches up, saving the downtime. It works, except that the converted slave is not reading the data from the master correctly anymore. When replication restarts, the data in the binlog is, I think, now being interpreted as UTF8 when it was encoded as latin1. That means we can't use this approach. As it takes 6 or more hours to convert our database, we really want to avoid the downtime. Can we somehow configure the replication slave to expect this latin1 encoding, but to store in UTF8 ? Has anyone tried a process like this?

Thanks,
Kevin

utf8 conversion problem (no replies)

$
0
0
Hi,
I am working as an Instructor in one of the private universities in Turkey.



I decided to transfer all my private programs to unix. Now I installed Realbasic software for transferring vb6 programs. Also, decided to transfer Access db to Mysql db.
I have installed mysql 5.5.13 standard version to my pc working with Windows 7 Pc to get experienced.

Although i have created a sample table on my mysql db with Turkish names using character set utf8, Turkish characters are always displayed Microsoft Windows Codepage 1254 (Turk) by workbench.

How can store these values with correct utf8.? Is this a problem reported to MYSql windows software?

For example turkish i without dot is displayed like ı

Please help me


Hilmi Oncul

COLLATION not valid (2 replies)

$
0
0
In 5.1.37, the following works:

select * from subid where sourceID=17467 and subid='ymjjc2vlaw' collate latin1_swedish_ci;

However, in 5.5.12 this error is generated:

ERROR 1253 (42000): COLLATION 'latin1_swedish_ci' is not valid for CHARACTER SET 'utf8'

I've found similar issues in my searches, but it's not clear to me how to modify the query in order for this to work. Any help is appreciated.

regexp for unicode control chars (no replies)

$
0
0
Hi,
How can I find all records that have unicode control characters?
This would be given in java by the following regexp...
\p{C}

But this query does not give results...
select * from tab where col regexp '\p{C}';

Please help.

case sensitive collation does not seem to work in 5.5 (no replies)

$
0
0
Hi all experts out there.

Under realease 5.0.66 we had created a new case sensitive collation latin1_german1_cs.
Everything worked well.
Key values like 'abc' and 'Abc' where stored in different rows.
Lately, we moved from 5.0.66 to 5.5.
Now our collation doesn't work anymore.
Storing a row with key 'Abc' while key 'abc' already exists yields 'Dupkey'.

Any idea?

Globalisation, UTF8 and characters with Accent. (no replies)

$
0
0
Hi,

I am very new to MySQL. I am trying to build a DB with names from all over the world. Most of the names have various accents associated with them.

1) The "Names" field has a "utf8_general_ci" collation
2) Reading names using XML and inserting them into the DB using a "perl script"

I am unable to get all the accents stored in the correct way! The names have "?" or have the Ascii code like "ě" or "ū". How Do I store it correctly?

I am unable to figure out if it is a "MySQL" Collation problem or a perl Problem.

Any help / advice is much appriciated.

Thank you in advance.

Problem In Inserting Unicode Data in Stored Procedures (no replies)

$
0
0
Hello
I am trying to insert some unicode data (hindi language) in a table.
Everything is ok, and data correctly get inserted in table if I am sending the data from a Query.
Problem raises if i am using the stored procedures.


Connection String defined in Web.Config

<add name="DBConnection" connectionString="server=localhost; userid=localuser; password=1234568987; database=DBUNICODEDATA; CharSet=utf8; pooling=false;"/>

CREATE TABLE `ztesthindi`
(
`rid` int(10) unsigned NOT NULL,
`engcontent` varchar(500) NOT NULL,
`hindicontent` text NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

(in this table 'hindicontent' column will contain the unicode data)

'----------------------- THIS ASP.NET 3.5 CODE WORKING PERFECTLY ------------------
Dim Qstr As String
Qstr = "INSERT INTO ztesthindi(rid, engcontent, hindicontent) values (110, '" & TextBox1.Text & "', '" & TextBox2.Text & "')"
Constring = ConfigurationManager.ConnectionStrings("DBConnection").ConnectionString
dbCon = New MySqlConnection(Constring)
dbCon.Open()
Dim MySqlCommand As New MySqlCommand("", dbCon)
MySqlCommand.CommandText = "SET character_set_results=utf8"
MySqlCommand.ExecuteNonQuery()
MySqlCommand.CommandText = "SET NAMES utf8"
MySqlCommand.ExecuteNonQuery()
MySqlCommand.CommandText = "SET character_set_client=utf8"
MySqlCommand.ExecuteNonQuery()
MySqlCommand.CommandText = "SET character_set_connection=utf8"
MySqlCommand.ExecuteNonQuery()
MySqlCommand.CommandText = "SET collation_connection=utf8_general_ci"
MySqlCommand.ExecuteNonQuery()
MySqlCommand.CommandText = Qstr
MySqlCommand.ExecuteNonQuery()
'-----------------------

The above asp.net 3.5 code is executing perfectly and inserting the data as well in the above table.

Now i created a stored procedure to insert the data in above table

CREATE DEFINER=`localuser`@`%` PROCEDURE `zAdd_ContentRow`(
IN p_engcontent VARCHAR(500),
IN p_hindicontent TEXT
)
BEGIN
DECLARE p_rid Integer;
Select Max(rid)+1 into p_rid From ztesthindi;
IF p_rid IS NULL THEN
SET p_rid = 101;
END IF;
SET character_set_results=utf8;
SET NAMES utf8;
SET character_set_client=utf8;
SET character_set_connection=utf8;
SET collation_connection=utf8_general_ci;
INSERT INTO ztesthindi VALUES(p_rid, p_engcontent, p_hindicontent);
END

The following code is returning error while trying to insert the row in above table.
"Incorrect string value: '\xE0\xA4\x90 \xE0\xA4...' for column 'p_hindicontent' at row 1"

Try
dbCon = New MySqlConnection
dbCon.ConnectionString = ConfigurationManager.ConnectionStrings("DBConnection").ConnectionString
dbCmd = New MySqlCommand
dbCmd.Connection = dbCon
dbCmd.CommandType = CommandType.StoredProcedure
dbCmd.CommandText = "zAdd_ContentRow"
dbCmd.Parameters.AddWithValue("p_engcontent", TextBox1.Text)
dbCmd.Parameters.AddWithValue("p_hindicontent", TextBox2.Text)
dbCon.Open()
dbCmd.ExecuteNonQuery()
Catch ex As Exception
Response.Write(ex.Message)
End Try

I tried to update the insert statement in stored proceudre
INSERT INTO ztesthindi VALUES(p_rid, p_engcontent, p_hindicontent);
with
INSERT INTO ztesthindi VALUES(p_rid, p_engcontent, convert(p_hindicontent using utf8));

but still getting the same error.

Please help me in this issue that how can i sortout the porblem.

Thank you.

Croatian characters not surviving LOAD DATA INFILE from UTF-8 .txt file (no replies)

$
0
0
I am trying to import some data from a .txt file set for UTF-8 into a new table that supports Croatian text. But some characters are not surviving the import. They show up as unknown characters.

Let me also add that this is a 5.5.12 MySQL Community Server (GPL) by Remi running on the latest CentOS distribution.

Here is the table,

delimiter $$

CREATE TABLE `abcd` (
  `xxxx4` varchar(100) CHARACTER SET latin1 NOT NULL DEFAULT 'xxxx4 Here',
  `xxxx5` varchar(100) CHARACTER SET latin2 COLLATE latin2_croatian_ci NOT NULL DEFAULT 'xxxx5 Here',
  `xxxx3` varchar(100) CHARACTER SET latin1 DEFAULT NULL,
  `xxxx2` varchar(200) CHARACTER SET latin2 COLLATE latin2_croatian_ci DEFAULT 'xxx2 Here',
  `xxxx1` varchar(100) CHARACTER SET latin1 NOT NULL DEFAULT 'xxxx1 Here',
  PRIMARY KEY (`xxxx5`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci$$

And here is a data sample

Acquitted**Mirjan Kupreškić++/w/index.php?title=Mirjan_Kupre%C5%A1ki%C4%87&amp;action=edit&amp;redlink=1**Bosnian Croat, HVO member**Lašva Valley massacres against Bosniak civilians**Acquitted on 23 October 2001.7++#cite_note-kupreskic-6
Acquitted**Vlatko Kupreškić++/w/index.php?title=Vlatko_Kupre%C5%A1ki%C4%87&amp;action=edit&amp;redlink=1**Bosnian Croat, HVO member**Lašva Valley massacres against Bosniak civilians**Acquitted on 23 October 2001.7++#cite_note-kupreskic-6

Here is how they show up:

'Acquitted', 'Mirjan Kupre??kiÄ?++/w/index.php?title=Mirjan_Kupre%C5%A1ki%C4%87&amp;action=edit&amp;redlink=1', 'Bosnian Croat, HVO member', 'La??va Valley massacres against Bosniak civilians', 'Acquitted on 23 October 2001.7++#cite_note-kupreskic-6'
'Acquitted', 'Vlatko Kupre??kiÄ?++/w/index.php?title=Vlatko_Kupre%C5%A1ki%C4%87&amp;action=edit&amp;redlink=1', 'Bosnian Croat, HVO member', 'La??va Valley massacres against Bosniak civilians', 'Acquitted on 23 October 2001.7++#cite_note-kupreskic-6'


The LOAD DATA INFILE command does not involve itself with character sets or collations as far as I know.

I already have a table in the same database that is showing the characters correctly and this table copies the attributes of that other table, such as column collation and table type and default collation for the table.

Notice the Croatian characters show up fine in this post.

What is going on? What do I change to make sure these characters survive the import?

Collation sort orders and digraphs (no replies)

$
0
0
Hi,

I found the documentation for adding a new collation to MySQL and it works fine! Except, there doesn't seem to be any instructions on how to treat a digraph as a single letter for sorting purposes. For example, the digraph 'ch' might be sorted after 'cz' as in utf8_spanish2_ci. Is it even possible to add this sort of thing to a custom collation? How would I go about doing this? Is there some documentation somewhere?

Thanks,
-Sylvia

latin1 to utf8 problem (1 reply)

$
0
0
Hi, i have a .sql script file and this is a db backup what i had done 3 years ago, now i want to restore it but there is more conflicts, because the charset of tables in script file is set to latin1 and table contains armenian characters, what character type i must use and what is the best way to convert latin1 texts to it
thanks

Emoji symbols in text columns (4 replies)

$
0
0
I'm trying to insert emoji symbols in a text column but I have this error:

java.sql.SQLException: Incorrect string value: '\xF0\x9F\x8D\x80No...' for column

I've tried also with the new utf8mb4 encoding but the error still occur.

Any idea?

Thanks

Fixing Double Enocoding With mysqldump (no replies)

$
0
0
Hi, I've just diagnosed my problem as "Double Encoding" as described by Rick James' incredibly helpful page at http://mysql.rjweb.org/doc.php/charcoll.

Indeed I have UTF8 data going in, a connection (erroneously) set to Latin1, and a database and tables set to UTF8. One 2 byte UTF8 character in ends up encoded as 4 bytes in my tables.

My question is about fixing it. It seems like by far the easiest thing to do would be:

1. mysqldump --default-character-set=latin1 .... my_database > my_database_latin1.sql
2. Edit my_database_latin1.sql to set NAMES=utf8 at the top.
3. mysql ... < mydatabase.sql

The dump should convert the 4 bytes which it thinks are 2 utf8 characters back down to 2 bytes (2 latin1 characters). The file should actually contain UTF8, though it thinks it's latin1. So change the encoding of the connection set at the top of the file to UTF8, and import this data back into the same database.

Since Rick doesn't quite mention this fix, I'm assuming I'm missing something. A quick test does look ok so far.

Am I missing something?

Thanks for the help - Peter

Illegal mix of collation during replication (no replies)

$
0
0
Occasionally, I get this error message in the mysql error log: "Error 'Illegal mix of collations (utf8_general_ci,COERCIBLE) and (latin1_swedish_ci,IMPLICIT) for operation '='' on query." during replication. The master is a "5.0.91-log MySQL Community Server", and the slave is "5.5.14-log MySQL Community Server". "utf8" is not configured anywhere in the my.cnf file. If I execute the statement manually on the slave, it still fails with the same error message. If I issue "SET character_set_connection=latin1;", I can continue replication by executing the statement manually, skip the statement in the replication, and start slave again.

I'm not sure if this is a bug, or I have something misconfigured. Any help is greatly appreciated.

Failed Query:
UPDATE A, B SET A.colA1 = B.B_PRIMARY_ID WHERE A.colA1='value' AND (INET_NTOA(A.IPADDR) = B.IPADDR) or A.IPADDR = B.IPADDR);

SHOW CREATE TABLE A:

CREATE TABLE A (
`colA1` int(10),
`IPADDR` varchar(128) NOT NULL DEFAULT '',

) ENGINE=InnoDB DEFAULT CHARSET=latin1;

SHOW FULL COLUMNS FROM A:
+------------------+---------------------+-------------------+------+-----+---------+----------------+---------------------------------+--------+
| Field | Type | Collation | Null | Key | Default | Extra | Privileges |Comment |
+-------------------+--------------------+-------------------+------+-----+---------+----------------+---------------------------------+--------+
| colA1 | int(10) unsigned | NULL | NO | PRI | 0 | | select,insert,update,references | |
| IPADDR | varchar(128) | latin1_swedish_ci | NO | | | | select,insert,update,references | |
+------------------+---------------------+-------------------+------+-----+---------+----------------+---------------------------------+--------+

SHOW CREATE TABLE B:

CREATE TABLE B (
`B_PRIMARY_ID` int(10),
`IPADDR` varchar(15) NOT NULL DEFAULT '',
PRIMARY KEY (`B_PRIMARY_ID`)
) ENGINE=InnoDB AUTO_INCREMENT=XXX DEFAULT CHARSET=latin1;

SHOW FULL COLUMNS FROM B:
+------------------+---------------------+-------------------+------+-----+---------+----------------+---------------------------------+---------+
| Field | Type | Collation | Null | Key | Default | Extra | Privileges | Comment |
+------------------+---------------------+-------------------+------+-----+---------+----------------+---------------------------------+---------+
| B_PRIMARY_ID | int(10) unsigned | NULL | NO | PRI | NULL | auto_increment | select,insert,update,references | |
| IPADDR | varchar(15) | latin1_swedish_ci | NO | MUL | | | select,insert,update,references | |
+------------------+---------------------+-------------------+------+-----+---------+----------------+---------------------------------+---------+

mysql> show global variables like '%collation%';
+----------------------+-------------------+
| Variable_name | Value |
+----------------------+-------------------+
| collation_connection | latin1_swedish_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
+----------------------+-------------------+
3 rows in set (0.00 sec)
Viewing all 294 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>