Building on my own investigations and @Larnu's SQL Fiddle, I've devised a little script to test two-letter combinations:
DECLARE @Letter VARCHAR(2);
SET @Letter = 'ch';
DECLARE @LetterA VARCHAR(1);
DECLARE @LetterB VARCHAR(1);
SET @LetterA = LEFT(@Letter, 1);
SET @LetterB = RIGHT(@Letter, 1);
SELECT CASE WHEN V.G = UPPER(@Letter) COLLATE Vietnamese_100_CI_AS_KS THEN 1 ELSE 0 END,
CASE WHEN V.G = LOWER(@Letter) COLLATE Vietnamese_100_CI_AS_KS THEN 1 ELSE 0 END,
CASE WHEN V.G = CONCAT(LOWER(@LetterA), UPPER(@LetterB)) COLLATE Vietnamese_100_CI_AS_KS THEN 1 ELSE 0 END,
CASE WHEN V.G = CONCAT(UPPER(@LetterA), LOWER(@LetterB)) COLLATE Vietnamese_100_CI_AS_KS THEN 1 ELSE 0 END
FROM (VALUES(@Letter COLLATE Vietnamese_100_CI_AS_KS)) V(G);
This will output 1 or 0 depending upon whether a comparison is valid for the two letter combination. The comparisons are:
- Upper case letters (i.e. NG)
- Lower case letters (i.e. ng)
- One upper case, one lower case letter (i.e. Ng)
- One lower case, one upper case letter (i.e. nG)
Running this for ab produces:
1 1 1 1
So ab does not exhibit this issue. However, for ch you get:
1 1 0 1
So ch does exhibit the same issue.
This seems related to declared consonants in the Vietnamese alphabet, which include these two-letter consonants:
Ch = 1 1 0 1 (has the same issue)
Gh = 1 1 0 1 (has the same issue)
Gi = 1 1 0 1 (has the same issue)
Kh = 1 1 0 1 (has the same issue)
Ng = 1 1 0 1 (has the same issue)
Nh = 1 1 0 1 (has the same issue)
Ph = 1 1 0 1 (has the same issue)
Qu = 1 1 0 1 (has the same issue)
Th = 1 1 0 1 (has the same issue)
Tr = 1 1 0 1 (has the same issue)
Unfortunately, I do not know why these are affected by this issue, which is not helpful. In addition, I don't know why it only affects the column name when it is a lowercase followed by an uppercase letter.
Perhaps someone else may see this and know the answer?
The reference for the alphabet is here.
Gcharacter?Vietnamese_100_CI_AS_KScollation or create a new database with that collation and create the table as non-temporary. I can reproduce the issueng. If you create a columnnG, then usingngcauses the same failure. However, if it'saG, there is no case sensitivity...nGas well, @Martin . I was explicitly testingG, notnG. (DB<>Fiddle)