标签: collation

我尝试使用存储过程来创建索引，但出现以下错误：

ERROR 1267 (HY000): Illegal mix of collations (utf8_general_ci,IMPLICIT) and 
                    (utf8_unicode_ci,IMPLICIT) for operation '='

没有行号或任何其他调试提示。

• 调试此错误的最佳方法是什么？
• 有什么好的指导方针可以避免编码不一致吗？

我们需要对通常是需要“自然”排序的数字和字母混合字符串的值进行一些报告。诸如“P7B18”或“P12B3”之类的东西。@字符串将主要是字母序列然后数字交替。但是，这些段的数量和每个段的长度可能会有所不同。

我们希望这些数字部分按数字顺序排序。显然，如果我直接用 处理这些字符串值ORDER BY，那么“P12B3”将在“P7B18”之前出现，因为“P1”早于“P7”，但我希望相反，因为“P7”自然在前面“P12”。

我还希望能够进行范围比较，例如@bin < 'P13S6'或类似的。我不必处理浮点数或负数；这些将严格是我们正在处理的非负整数。字符串长度和段数可能是任意的，没有固定的上限。

在我们的例子中，字符串大小写并不重要，但如果有一种方法可以以排序方式感知方式做到这一点，其他人可能会发现这很有用。所有这一切中最丑陋的部分是我希望能够在WHERE子句中进行排序和范围过滤。

如果我在 C# 中执行此操作，这将是一项非常简单的任务：进行一些解析以将 alpha 与数字分开，实现 IComparable，您基本上就完成了。当然，SQL Server 似乎没有提供任何类似的功能，至少就我所知。

任何人都知道使这项工作有什么好的技巧吗？是否有一些很少公开的能力来创建实现 IComparable 的自定义 CLR 类型并使其按预期运行？我也不反对 Stupid XML Tricks（另请参阅：list concatenation），而且我在服务器上也提供了 CLR 正则表达式匹配/提取/替换包装函数。

编辑： 作为一个更详细的例子，我希望数据表现得像这样。

SELECT bin FROM bins ORDER BY bin

bin
--------------------
M7R16L
P8RF6JJ
P16B5
PR7S19
PR7S19L
S2F3
S12F0

即将字符串分成所有字母或所有数字的标记，并分别按字母或数字对它们进行排序，最左边的标记是最重要的排序项。就像我提到的，如果您实现 IComparable，在 .NET 中是小菜一碟，但我不知道如何（或是否）您可以在 SQL Server 中执行此类操作。这肯定不是我在 10 年左右的工作中遇到过的事情。

我刚刚从我的客户那里收到了一个应用程序的源代码和数据库（它是由来自不同国家的另一家公司开发的），并且该应用程序抛出了一些与对象整理相关的异常：

无法解决 equal to 操作中“SQL_Latin1_General_CP1_CI_AS”和“Latin1_General_CI_AS”之间的排序规则冲突。

我看到，在我的情况下，这是由于存储过程创建了一个 #temp 表并且该#temp表用于与应用程序中的表（应用程序数据库使用SQL_Latin1_General_CP1_CI_AS和tempdb使用Latin1_General_CI_AS）进行比较时引起的。

我加入COLLATE SQL_Latin1_General_CP1_CI_AS的CREATE TABLE #TEMPTABLE声明，但是这个数据库有很多存储过程可以使用#temp表。

如何在不破坏其他数据库/应用程序的情况下更快地解决这个问题？

我正在尝试创建一个触发器，以在创建时更改数据库的排序规则，但是如何捕获要在触发器内部使用的数据库名称？

USE master
GO
CREATE TRIGGER trg_DDL_ChangeCOllationDatabase
ON ALL SERVER
FOR CREATE_DATABASE
AS
declare @databasename varchar(200)
set @databasename =db_name()
    ALTER DATABASE @databasename COLLATE xxxxxxxxxxxxxxxxxxx
GO

显然，这是行不通的。

我有需要支持 3 种不同语言的新 SQL Server 数据库。

如果我希望我的数据库支持以下内容，我需要选择哪些字符集和排序规则：

• 希伯来语
• 阿拉伯
• 英语
• 法语

Unicode代码点9619是一个叫“深色”字符：?（http://unicode-table.com/en/search/?q=9619）。

使用SQL_Latin1_General_CP1_CI_AS排序规则和 1252 代码页，我希望将该 Unicode 字符转换/转换为非 Unicode 数据类型会导致问号 ( ?)，因为代码页 1252 似乎不包含此字符，这似乎是 SQL Server 的无法进行转换时的行为。

所以我的问题是：为什么 SQL Server 将此字符转换为 ASCII 代码 166，即“管道，垂直竖线”：¦？

SELECT NCHAR(9619), CAST(NCHAR(9619) AS CHAR(1)), ASCII(CAST(NCHAR(9619) AS CHAR(1)))

我有一个使用 mysqldump 导出的 mysql 8.0。我正在尝试使用 phpmyadmin 将它导入到 Mariadb 10.4 数据库中，两者都是最新版本。每次我这样做时，我都会得到：

Error: Unknown collation utf8mb4_0900_ai_ci

然后我回到 sql 文件并替换utf8mb4_0900_ai_ci为utf8mb4_general_ci，但是它说各种CREATE VIEWsql 语句都有错误。我可以尝试其他快速、无错误的修复吗？

目前我正在试图创建一个表，一个文本列将比较案例在默认情况下是敏感的。这是因为我们有一个第三方程序可以对我们的数据库执行搜索。该SELECT程序使用的语句不能更改。

抽象的问题是我们不知何故需要这个搜索不区分大小写，但它目前是区分大小写的。

我读到 Postgres 12 确实支持允许这种行为的非确定性排序规则。

我在德国 Windows 机器上安装了 Postgres 服务器（版本 PostgreSQL 12.1，由 Visual C++ build 1914 编译，64 位）。

因此，出于测试目的，我创建了一个新数据库进行测试：

CREATE DATABASE collation_test
    WITH 
    OWNER = postgres
    ENCODING = 'UTF8'
    CONNECTION LIMIT = -1;

在这个数据库中，我创建了以下排序规则，我在一篇关于这些排序规则的文章中找到了

CREATE COLLATION collat_ci (
  provider = 'icu',
  locale = 'und-u-ks-level2',
  deterministic = false
);

在此之后，我需要一个表来测试这个排序规则

CREATE TABLE public.person
(
    "Id" bigint NOT NULL,
    "Name" text COLLATE public.collat_ci,
    PRIMARY KEY ("Id")
);

ALTER TABLE public.person
    OWNER to postgres;

INSERT …

我在一家公司工作，该公司定期从客户那里接收大型 SQL 数据库备份以用于支持目的。我们支持多个 SQL 版本和排序规则，但目前必须手动确认我们客户端的 SQL 版本，然后才能恢复到正确的 SQL 实例。我想知道是否有办法自动化这个过程。

我期待：

1. 查找备份数据库的 SQL Server 版本（我们得到 2008 R2 以及 2014 和 2017）
2. 查找数据库的默认排序规则

无需完全恢复到可能不正确的 SQL 实例，由于其大小，这需要大量时间。（也许是零碎的恢复？）

我们有一个场景，我们希望将生产数据库（包括列）的排序规则从 SQL_Scandinavian_Pref_CP850_CI_AS 更改为 Finnish_Swedish_CI_AS。我们已经开发了脚本来做到这一点。但是在超过 100GB 的大型数据库中执行此脚本将需要相当长的时间，而且我们不能承受很长时间的停机时间。因此，我们决定使用以下策略来减少停机时间：

1. 我们将设置事务复制，我们将使用数据库备份方法初始化订阅者。
2. 发布者数据库将与应用程序一起使用，其事务将通过事务复制传递到订阅者数据库。
3. 我们将在订阅者端执行排序规则更改脚本，当 SQL Server 对发布者和订阅者数据库相同时，它确实允许我们执行此脚本。我们最近在 SQL Server 2019 中发现了这一点。
4. 现在，痛点是，当 varchar、char 列的数据包含诸如“åÅääÄöÖ”之类的特殊字符时，它无法正确复制。在订阅者方面，我们收到了像“†„Ž”™“这样的奇怪字符

您能否建议我们如何解决此错误或任何替代架构，以在更改数据库排序规则（包括列）时最大限度地减少生产停机时间？

此外，我的排序规则更改脚本正在订阅者数据库上执行以下任务以更改其排序规则：

1. 删除外键约束
2. 删除包括主键在内的索引
3. 删除检查和默认约束
4. 删除用户统计
5. 删除视图、计算列、SP 以解决对象绑定错误
6. 执行上述步骤后，表已准备好进行整理更改。因此，脚本将一一更改每个表的列的排序规则。
7. 成功执行第 6 步后，重新创建上面列出的约束。