SQL Server conflict between “Chinese_PRC_CI_AS_WS“ and “Albanian_100_BIN“ in the equal to operation.

由于排序规则不同,导致 join 时报错:
Cannot resolve the collation conflict between "Chinese_PRC_CI_AS_WS" and "Albanian_100_BIN" in the equal to operation.

由于排序规则不同,导致 union all  时报错:
Implicit conversion of varchar value to varchar cannot be performed because the collation of the value is unresolved due to a collation conflict between "Chinese_PRC_CI_AS_WS" and "Albanian_100_BIN" in UNION ALL operator.


在join 或union all 时加上  COLLATE Chinese_PRC_CI_AS_WS 或者COLLATE Albanian_100_BIN 就可以了

①、加上  COLLATE Chinese_PRC_CI_AS_WS

select * from tmpTB_1 t1 left join tmpTB_2 t2 on t1.Name COLLATE Chinese_PRC_CI_AS_WS = t2.Name

①、加上  COLLATE Albanian_100_BIN

select * from tmpTB_1 t1 left join tmpTB_2 t2 on t1.Name = t2.Name COLLATE Albanian_100_BIN

 

version_conflict_engine_exception是一种在Elasticsearch中可能遇到的错误。当多个用户或进程尝试并发地更新同一个文档时,就会引发这个异常。 Elasticsearch中的每个文档都有一个称为_version的字段,用于跟踪文档的版本。当用户或进程尝试更新一个文档时,Elasticsearch会检查当前版本和请求中指定的版本是否匹配。如果不匹配,就会引发version_conflict_engine_exception。 这个异常的出现通常是由于并发更新操作引起的。例如,当两个用户同时尝试更新同一个文档时,其中一个用户的更新操作会成功,而另一个用户的更新操作由于版本冲突而失败。 为了解决这个问题,可以采取以下几种方法: 1. 使用乐观并发控制:在更新文档之前,先获取当前版本,并将该版本传递给更新操作。如果版本匹配,更新就会成功。如果不匹配,则可以根据情况选择重试或者返回错误信息给用户。 2. 使用悲观并发控制:在更新文档时,使用锁定机制确保同一时间只有一个用户可以更新文档。其他用户必须等待直到锁被释放后才能进行更新操作。这种方法可以保证不会出现版本冲突,但会影响系统的并发性能。 3. 使用分布式锁:如果有多个Elasticsearch节点,可以使用分布式锁来控制并发更新操作。通过在更新操作之前申请分布式锁,可以确保同一时间只有一个节点可以更新文档。 总之,version_conflict_engine_exception是Elasticsearch在并发更新操作中可能出现的异常。为了解决这个问题,可以使用乐观或悲观并发控制,或者使用分布式锁来确保操作的一致性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值