ODBC SQL Server Unicode Bug？

Question

背景：

我们有一个应用程序，它使用ODBC与Access和Server进行交互(动态地，取决于用户的配置)。

我发现了一个错误，它可能在ODBC驱动程序中，或者可能是我们创建的ODBC DSN中的一个错误配置问题，或者可能是代码中的一个bug。

在编辑和保存文档时，我们查询数据库以查看该文件是否在数据库中有相应的记录--如果是这样，则使用文档中更新的数据更新记录；如果没有，则执行insert来为其创建必要的记录。

我们使用文件名作为表中唯一的主键，并且正常工作。错误是，如果文件名包含当前ANSI代码页之外的字符，则选择指示不匹配：

   SQL:  SELECT * FROM "My Designs" WHERE "PATHNAME" = '\\FILE-SERVER\Home Folders\User Files\狭すぎて丸め処理が出来ません!!.foo'   [# matches = 0]

但是，当尝试插入时，我们会得到一个唯一的密钥冲突(当然)--因为已经有一个带有该文件名的记录。

Database error: Violation of PRIMARY KEY constraint 'PK__My Desig__1B3D5B4BF643706B'. Cannot insert duplicate key in object 'dbo.My Designs'. The duplicate key value is (\\FILE-SERVER\Home Folders\User Files\狭すぎて丸め処理が出来ません!!.foo).
The statement has been terminated.

我仔细看了一遍密码，没发现有什么问题。:(

正在生成的SQL语句生成文件名的正确Unicode输出。我们的应用程序是为Unicode编译的。列是ODBC中的SQL_WVARCHAR。

我尝试过将AutoTranslate=no添加到DSN配置字符串中，但这似乎没有任何效果。

我尝试过从ODBC控制面板记录数据库连接。遗憾的是，该接口生成一个ANSI日志文件，因此我无法使用该工具验证UNICODE / ANSI问题。

问题：

• 是否有一个工具可以用来验证这些语句是否由ODBC驱动程序正确地创建/发出到Server数据库？
• 是否有更好的方法来使用ODBC，这样驱动程序就不会在SELECT查询和INSERT请求中被一个简单的UNICODE字符串引导？
• 关于如何解决这个问题的任何其他想法(除了替换我们的技术)

Answer 1

在select语句中，确保将where子句字符串用N括起来，以告诉SQL它是unicode：

..."PATHNAME" = N'\\FILE-SERVER\Home Folders\User Files\狭すぎて丸め処理が出来ません!!.foo'

此外，MFC根据配置将数据转换为MCBS或UNICODE。确保在记录集中使用CStringT。