Mixing
mysql error 1062 during alter table modify column
I have a table that looks like this:
CREATE TABLE t1 (
id BIGINT AUTO_INCREMENT NOT NULL PRIMARY KEY,
col1 VARCHAR(256),
UNIQUE INDEX t1_col1_index (col1)
)
I'm trying to modify the col1 type using the following query:
ALTER TABLE t1 MODIFY COLUMN col1 varchar(191) COLLATE utf8mb4_unicode_ci;
However, I run into this duplication error:
error: ("1062", "QMYSQL3: Unable to execute statement", "Duplicate entry '+123456789' for key 't1_col1_index'")
I initially thought it could be because two or more rows might 'contain' similar value for col1 and on changing varchar length the data gets truncated but then I found out that data truncation wouldn't even allow the query to go through. Any pointers on what could be causing this?
EDIT (Resolved): Truncation does happen when @@sql_mode is not set with STRICT_TRANS_TABLES. This was causing the error.
mysql qt qsqlquery
asked Jan 3 at 0:34
DjokerSDjokerS
5910
add a comment |
I have a table that looks like this:
CREATE TABLE t1 (
id BIGINT AUTO_INCREMENT NOT NULL PRIMARY KEY,
col1 VARCHAR(256),
UNIQUE INDEX t1_col1_index (col1)
)
I'm trying to modify the col1 type using the following query:
ALTER TABLE t1 MODIFY COLUMN col1 varchar(191) COLLATE utf8mb4_unicode_ci;
However, I run into this duplication error:
error: ("1062", "QMYSQL3: Unable to execute statement", "Duplicate entry '+123456789' for key 't1_col1_index'")
I initially thought it could be because two or more rows might 'contain' similar value for col1 and on changing varchar length the data gets truncated but then I found out that data truncation wouldn't even allow the query to go through. Any pointers on what could be causing this?
EDIT (Resolved): Truncation does happen when @@sql_mode is not set with STRICT_TRANS_TABLES. This was causing the error.
mysql qt qsqlquery
asked Jan 3 at 0:34
DjokerSDjokerS
5910
The issue may caused by collation of column, when the previous collation is case sensitive and you try to change it to case insensitive.
– Hamlet Hakobyan
Jan 3 at 0:41
Interesting, thanks for the pointer! Is there a way to verify this, or dig more deeper into this? The reason I'm asking this is because I'm just storing numbers in col1, with occasional '+' symbol. Trying to see what might have caused this issue.
– DjokerS
Jan 3 at 0:56
Also, shouldn't unicode collation handle such case sensitive issues?
– DjokerS
Jan 3 at 1:09
add a comment |
I have a table that looks like this:
CREATE TABLE t1 (
id BIGINT AUTO_INCREMENT NOT NULL PRIMARY KEY,
col1 VARCHAR(256),
UNIQUE INDEX t1_col1_index (col1)
)
I'm trying to modify the col1 type using the following query:
ALTER TABLE t1 MODIFY COLUMN col1 varchar(191) COLLATE utf8mb4_unicode_ci;
However, I run into this duplication error:
error: ("1062", "QMYSQL3: Unable to execute statement", "Duplicate entry '+123456789' for key 't1_col1_index'")
I initially thought it could be because two or more rows might 'contain' similar value for col1 and on changing varchar length the data gets truncated but then I found out that data truncation wouldn't even allow the query to go through. Any pointers on what could be causing this?
EDIT (Resolved): Truncation does happen when @@sql_mode is not set with STRICT_TRANS_TABLES. This was causing the error.
mysql qt qsqlquery
asked Jan 3 at 0:34
DjokerSDjokerS
5910
I have a table that looks like this:
CREATE TABLE t1 (
id BIGINT AUTO_INCREMENT NOT NULL PRIMARY KEY,
col1 VARCHAR(256),
UNIQUE INDEX t1_col1_index (col1)
)
I'm trying to modify the col1 type using the following query:
ALTER TABLE t1 MODIFY COLUMN col1 varchar(191) COLLATE utf8mb4_unicode_ci;
However, I run into this duplication error:
error: ("1062", "QMYSQL3: Unable to execute statement", "Duplicate entry '+123456789' for key 't1_col1_index'")
I initially thought it could be because two or more rows might 'contain' similar value for col1 and on changing varchar length the data gets truncated but then I found out that data truncation wouldn't even allow the query to go through. Any pointers on what could be causing this?
EDIT (Resolved): Truncation does happen when @@sql_mode is not set with STRICT_TRANS_TABLES. This was causing the error.
mysql qt qsqlquery
mysql qt qsqlquery
asked Jan 3 at 0:34
DjokerSDjokerS
5910
asked Jan 3 at 0:34
DjokerSDjokerS
5910
edited Jan 3 at 20:43
DjokerS
asked Jan 3 at 0:34
DjokerSDjokerS
5910
asked Jan 3 at 0:34
DjokerSDjokerS
5910
asked Jan 3 at 0:34
DjokerSDjokerS
5910
5910
The issue may caused by collation of column, when the previous collation is case sensitive and you try to change it to case insensitive.
– Hamlet Hakobyan
Jan 3 at 0:41
Interesting, thanks for the pointer! Is there a way to verify this, or dig more deeper into this? The reason I'm asking this is because I'm just storing numbers in col1, with occasional '+' symbol. Trying to see what might have caused this issue.
– DjokerS
Jan 3 at 0:56
Also, shouldn't unicode collation handle such case sensitive issues?
– DjokerS
Jan 3 at 1:09
add a comment |
The issue may caused by collation of column, when the previous collation is case sensitive and you try to change it to case insensitive.
– Hamlet Hakobyan
Jan 3 at 0:41
Interesting, thanks for the pointer! Is there a way to verify this, or dig more deeper into this? The reason I'm asking this is because I'm just storing numbers in col1, with occasional '+' symbol. Trying to see what might have caused this issue.
– DjokerS
Jan 3 at 0:56
Also, shouldn't unicode collation handle such case sensitive issues?
– DjokerS
Jan 3 at 1:09
The issue may caused by collation of column, when the previous collation is case sensitive and you try to change it to case insensitive.
– Hamlet Hakobyan
Jan 3 at 0:41
The issue may caused by collation of column, when the previous collation is case sensitive and you try to change it to case insensitive.
– Hamlet Hakobyan
Jan 3 at 0:41
Interesting, thanks for the pointer! Is there a way to verify this, or dig more deeper into this? The reason I'm asking this is because I'm just storing numbers in col1, with occasional '+' symbol. Trying to see what might have caused this issue.
– DjokerS
Jan 3 at 0:56
Interesting, thanks for the pointer! Is there a way to verify this, or dig more deeper into this? The reason I'm asking this is because I'm just storing numbers in col1, with occasional '+' symbol. Trying to see what might have caused this issue.
– DjokerS
Jan 3 at 0:56
Also, shouldn't unicode collation handle such case sensitive issues?
– DjokerS
Jan 3 at 1:09
Also, shouldn't unicode collation handle such case sensitive issues?
– DjokerS
Jan 3 at 1:09
add a comment |
2 Answers
2
active
oldest
votes
You are reducing the length of a varchar column that is controlled by a UNIQUE constraint.
This is risky business. Oversize data will be silently trimed (unless you have the @@sql_mode set to STRICT_TRANS_TABLES in which case an error will be raised). This probably generates duplicates, which cause the error to be raised by your UNIQUE constraint.
You can check the max length of the values in your column with :
SELECT MAX(CHAR_LENGTH(col1)) FROM t1:
answered Jan 3 at 1:48
GMBGMB
21k51028
You're mixingCHARACTER SETandCOLLATE.
– sticky bit
Jan 3 at 1:56
@stickybit : I was starting to wonder... So changing the collation does not generate data conversion, right ?
– GMB
Jan 3 at 2:05
@stickybit I updated my anwer to focus on the size reduction of the column
– GMB
Jan 3 at 2:16
As I understand it, no. But changing the collation might change the cases when two strings are considered equal. So in general your answer may be right. But without sample data and the collation before the change that's hardly testable.
– sticky bit
Jan 3 at 2:17
That is not entirely true. If I change the varchar to a length smaller than the max char_length of a column the sql query fails with the following error: ERROR 1265 (01000): Data truncated for column 'col1' at row 9322
– DjokerS
Jan 3 at 19:12
|
show 2 more comments
I am not sure if this is work.
Try to check the table t1.
select count(1) from t1 where col1 = 123456789
Now if count is greater than one then try to remove the other one and leave only one record.
Then try to run your statement again.
Reminder:
Do back up first before removing.
answered Jan 3 at 0:52
Vijunav VastivchVijunav Vastivch
3,4311724
Sorry, I edited the problem statement. It's a unique index. There's no duplicate entry.
– DjokerS
Jan 3 at 0:54
How about this wayALTER TABLE t1 ALTER COLUMN col1 varchar(191) COLLATE utf8mb4_unicode_ci;You can temporarily remove the index first then put it back whenALTERhas been done.
– Vijunav Vastivch
Jan 3 at 1:02
If unicode collation scheme considers two values as same, shouldn't that still be a problem when I try to create an index after changing column type? Basically, there are two values that are equal according to this collation which are now present in the table, creating an index on this should fail, right?
– DjokerS
Jan 3 at 1:11
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54014953%2fmysql-error-1062-during-alter-table-modify-column%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
You are reducing the length of a varchar column that is controlled by a UNIQUE constraint.
This is risky business. Oversize data will be silently trimed (unless you have the @@sql_mode set to STRICT_TRANS_TABLES in which case an error will be raised). This probably generates duplicates, which cause the error to be raised by your UNIQUE constraint.
You can check the max length of the values in your column with :
SELECT MAX(CHAR_LENGTH(col1)) FROM t1:
answered Jan 3 at 1:48
GMBGMB
21k51028
You're mixingCHARACTER SETandCOLLATE.
– sticky bit
Jan 3 at 1:56
@stickybit : I was starting to wonder... So changing the collation does not generate data conversion, right ?
– GMB
Jan 3 at 2:05
@stickybit I updated my anwer to focus on the size reduction of the column
– GMB
Jan 3 at 2:16
As I understand it, no. But changing the collation might change the cases when two strings are considered equal. So in general your answer may be right. But without sample data and the collation before the change that's hardly testable.
– sticky bit
Jan 3 at 2:17
That is not entirely true. If I change the varchar to a length smaller than the max char_length of a column the sql query fails with the following error: ERROR 1265 (01000): Data truncated for column 'col1' at row 9322
– DjokerS
Jan 3 at 19:12
|
show 2 more comments
You are reducing the length of a varchar column that is controlled by a UNIQUE constraint.
This is risky business. Oversize data will be silently trimed (unless you have the @@sql_mode set to STRICT_TRANS_TABLES in which case an error will be raised). This probably generates duplicates, which cause the error to be raised by your UNIQUE constraint.
You can check the max length of the values in your column with :
SELECT MAX(CHAR_LENGTH(col1)) FROM t1:
answered Jan 3 at 1:48
GMBGMB
21k51028
You're mixingCHARACTER SETandCOLLATE.
– sticky bit
Jan 3 at 1:56
@stickybit : I was starting to wonder... So changing the collation does not generate data conversion, right ?
– GMB
Jan 3 at 2:05
@stickybit I updated my anwer to focus on the size reduction of the column
– GMB
Jan 3 at 2:16
As I understand it, no. But changing the collation might change the cases when two strings are considered equal. So in general your answer may be right. But without sample data and the collation before the change that's hardly testable.
– sticky bit
Jan 3 at 2:17
That is not entirely true. If I change the varchar to a length smaller than the max char_length of a column the sql query fails with the following error: ERROR 1265 (01000): Data truncated for column 'col1' at row 9322
– DjokerS
Jan 3 at 19:12
|
show 2 more comments
You are reducing the length of a varchar column that is controlled by a UNIQUE constraint.
This is risky business. Oversize data will be silently trimed (unless you have the @@sql_mode set to STRICT_TRANS_TABLES in which case an error will be raised). This probably generates duplicates, which cause the error to be raised by your UNIQUE constraint.
You can check the max length of the values in your column with :
SELECT MAX(CHAR_LENGTH(col1)) FROM t1:
answered Jan 3 at 1:48
GMBGMB
21k51028
You are reducing the length of a varchar column that is controlled by a UNIQUE constraint.
This is risky business. Oversize data will be silently trimed (unless you have the @@sql_mode set to STRICT_TRANS_TABLES in which case an error will be raised). This probably generates duplicates, which cause the error to be raised by your UNIQUE constraint.
You can check the max length of the values in your column with :
SELECT MAX(CHAR_LENGTH(col1)) FROM t1:
answered Jan 3 at 1:48
GMBGMB
21k51028
edited Jan 3 at 20:49
answered Jan 3 at 1:48
GMBGMB
21k51028
answered Jan 3 at 1:48
GMBGMB
21k51028
answered Jan 3 at 1:48
GMBGMB
21k51028
21k51028
You're mixingCHARACTER SETandCOLLATE.
– sticky bit
Jan 3 at 1:56
@stickybit : I was starting to wonder... So changing the collation does not generate data conversion, right ?
– GMB
Jan 3 at 2:05
@stickybit I updated my anwer to focus on the size reduction of the column
– GMB
Jan 3 at 2:16
As I understand it, no. But changing the collation might change the cases when two strings are considered equal. So in general your answer may be right. But without sample data and the collation before the change that's hardly testable.
– sticky bit
Jan 3 at 2:17
That is not entirely true. If I change the varchar to a length smaller than the max char_length of a column the sql query fails with the following error: ERROR 1265 (01000): Data truncated for column 'col1' at row 9322
– DjokerS
Jan 3 at 19:12
|
show 2 more comments
You're mixingCHARACTER SETandCOLLATE.
– sticky bit
Jan 3 at 1:56
@stickybit : I was starting to wonder... So changing the collation does not generate data conversion, right ?
– GMB
Jan 3 at 2:05
@stickybit I updated my anwer to focus on the size reduction of the column
– GMB
Jan 3 at 2:16
As I understand it, no. But changing the collation might change the cases when two strings are considered equal. So in general your answer may be right. But without sample data and the collation before the change that's hardly testable.
– sticky bit
Jan 3 at 2:17
That is not entirely true. If I change the varchar to a length smaller than the max char_length of a column the sql query fails with the following error: ERROR 1265 (01000): Data truncated for column 'col1' at row 9322
– DjokerS
Jan 3 at 19:12
You're mixing
CHARACTER SET and COLLATE.– sticky bit
Jan 3 at 1:56
You're mixing
CHARACTER SET and COLLATE.– sticky bit
Jan 3 at 1:56
@stickybit : I was starting to wonder... So changing the collation does not generate data conversion, right ?
– GMB
Jan 3 at 2:05
@stickybit : I was starting to wonder... So changing the collation does not generate data conversion, right ?
– GMB
Jan 3 at 2:05
@stickybit I updated my anwer to focus on the size reduction of the column
– GMB
Jan 3 at 2:16
@stickybit I updated my anwer to focus on the size reduction of the column
– GMB
Jan 3 at 2:16
As I understand it, no. But changing the collation might change the cases when two strings are considered equal. So in general your answer may be right. But without sample data and the collation before the change that's hardly testable.
– sticky bit
Jan 3 at 2:17
As I understand it, no. But changing the collation might change the cases when two strings are considered equal. So in general your answer may be right. But without sample data and the collation before the change that's hardly testable.
– sticky bit
Jan 3 at 2:17
That is not entirely true. If I change the varchar to a length smaller than the max char_length of a column the sql query fails with the following error: ERROR 1265 (01000): Data truncated for column 'col1' at row 9322
– DjokerS
Jan 3 at 19:12
That is not entirely true. If I change the varchar to a length smaller than the max char_length of a column the sql query fails with the following error: ERROR 1265 (01000): Data truncated for column 'col1' at row 9322
– DjokerS
Jan 3 at 19:12
|
show 2 more comments
I am not sure if this is work.
Try to check the table t1.
select count(1) from t1 where col1 = 123456789
Now if count is greater than one then try to remove the other one and leave only one record.
Then try to run your statement again.
Reminder:
Do back up first before removing.
answered Jan 3 at 0:52
Vijunav VastivchVijunav Vastivch
3,4311724
Sorry, I edited the problem statement. It's a unique index. There's no duplicate entry.
– DjokerS
Jan 3 at 0:54
How about this wayALTER TABLE t1 ALTER COLUMN col1 varchar(191) COLLATE utf8mb4_unicode_ci;You can temporarily remove the index first then put it back whenALTERhas been done.
– Vijunav Vastivch
Jan 3 at 1:02
If unicode collation scheme considers two values as same, shouldn't that still be a problem when I try to create an index after changing column type? Basically, there are two values that are equal according to this collation which are now present in the table, creating an index on this should fail, right?
– DjokerS
Jan 3 at 1:11
add a comment |
I am not sure if this is work.
Try to check the table t1.
select count(1) from t1 where col1 = 123456789
Now if count is greater than one then try to remove the other one and leave only one record.
Then try to run your statement again.
Reminder:
Do back up first before removing.
answered Jan 3 at 0:52
Vijunav VastivchVijunav Vastivch
3,4311724
Sorry, I edited the problem statement. It's a unique index. There's no duplicate entry.
– DjokerS
Jan 3 at 0:54
How about this wayALTER TABLE t1 ALTER COLUMN col1 varchar(191) COLLATE utf8mb4_unicode_ci;You can temporarily remove the index first then put it back whenALTERhas been done.
– Vijunav Vastivch
Jan 3 at 1:02
If unicode collation scheme considers two values as same, shouldn't that still be a problem when I try to create an index after changing column type? Basically, there are two values that are equal according to this collation which are now present in the table, creating an index on this should fail, right?
– DjokerS
Jan 3 at 1:11
add a comment |
I am not sure if this is work.
Try to check the table t1.
select count(1) from t1 where col1 = 123456789
Now if count is greater than one then try to remove the other one and leave only one record.
Then try to run your statement again.
Reminder:
Do back up first before removing.
answered Jan 3 at 0:52
Vijunav VastivchVijunav Vastivch
3,4311724
I am not sure if this is work.
Try to check the table t1.
select count(1) from t1 where col1 = 123456789
Now if count is greater than one then try to remove the other one and leave only one record.
Then try to run your statement again.
Reminder:
Do back up first before removing.
answered Jan 3 at 0:52
Vijunav VastivchVijunav Vastivch
3,4311724
answered Jan 3 at 0:52
Vijunav VastivchVijunav Vastivch
3,4311724
answered Jan 3 at 0:52
Vijunav VastivchVijunav Vastivch
3,4311724
answered Jan 3 at 0:52
Vijunav VastivchVijunav Vastivch
3,4311724
3,4311724
Sorry, I edited the problem statement. It's a unique index. There's no duplicate entry.
– DjokerS
Jan 3 at 0:54
How about this wayALTER TABLE t1 ALTER COLUMN col1 varchar(191) COLLATE utf8mb4_unicode_ci;You can temporarily remove the index first then put it back whenALTERhas been done.
– Vijunav Vastivch
Jan 3 at 1:02
If unicode collation scheme considers two values as same, shouldn't that still be a problem when I try to create an index after changing column type? Basically, there are two values that are equal according to this collation which are now present in the table, creating an index on this should fail, right?
– DjokerS
Jan 3 at 1:11
add a comment |
Sorry, I edited the problem statement. It's a unique index. There's no duplicate entry.
– DjokerS
Jan 3 at 0:54
How about this wayALTER TABLE t1 ALTER COLUMN col1 varchar(191) COLLATE utf8mb4_unicode_ci;You can temporarily remove the index first then put it back whenALTERhas been done.
– Vijunav Vastivch
Jan 3 at 1:02
If unicode collation scheme considers two values as same, shouldn't that still be a problem when I try to create an index after changing column type? Basically, there are two values that are equal according to this collation which are now present in the table, creating an index on this should fail, right?
– DjokerS
Jan 3 at 1:11
Sorry, I edited the problem statement. It's a unique index. There's no duplicate entry.
– DjokerS
Jan 3 at 0:54
Sorry, I edited the problem statement. It's a unique index. There's no duplicate entry.
– DjokerS
Jan 3 at 0:54
How about this way
ALTER TABLE t1 ALTER COLUMN col1 varchar(191) COLLATE utf8mb4_unicode_ci; You can temporarily remove the index first then put it back when ALTER has been done.– Vijunav Vastivch
Jan 3 at 1:02
How about this way
ALTER TABLE t1 ALTER COLUMN col1 varchar(191) COLLATE utf8mb4_unicode_ci; You can temporarily remove the index first then put it back when ALTER has been done.– Vijunav Vastivch
Jan 3 at 1:02
If unicode collation scheme considers two values as same, shouldn't that still be a problem when I try to create an index after changing column type? Basically, there are two values that are equal according to this collation which are now present in the table, creating an index on this should fail, right?
– DjokerS
Jan 3 at 1:11
If unicode collation scheme considers two values as same, shouldn't that still be a problem when I try to create an index after changing column type? Basically, there are two values that are equal according to this collation which are now present in the table, creating an index on this should fail, right?
– DjokerS
Jan 3 at 1:11
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54014953%2fmysql-error-1062-during-alter-table-modify-column%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
The issue may caused by collation of column, when the previous collation is case sensitive and you try to change it to case insensitive.
– Hamlet Hakobyan
Jan 3 at 0:41
Interesting, thanks for the pointer! Is there a way to verify this, or dig more deeper into this? The reason I'm asking this is because I'm just storing numbers in col1, with occasional '+' symbol. Trying to see what might have caused this issue.
– DjokerS
Jan 3 at 0:56
Also, shouldn't unicode collation handle such case sensitive issues?
– DjokerS
Jan 3 at 1:09