我在使用LiveCode时遇到此问题，但我不知道问题所在的位置是否存在，或者是否与ODBC驱动程序有关。
LiveCode内置的应用程序定期通过ODBC连接到SQL Server数据库，以检索各种数据。
正在升级负责数据库的应用程序，并且作为其一部分，所有文本字段都将转换为Unicode文本字段。从本质上讲，这意味着先前定义为varchar的字段现在定义为nvarchar，之前定义为text的字段现在定义为ntext。 （顺便说一下，这是SQL Server 2008。）
使用我们过去一直使用的查询，我们现在得到一个字符（字段中的第一个字符）而不是整个文本。我现在可以通过在select查询中指定转换为varchar来解决此问题，例如用于发出请求的应用程序 SELECT id，名称FROM tab1 它现在提出了一个请求 SELECT id，convert（varchar（255），name）AS name FROM tab1
这样做 - 我得到了我以前得到的东西 - 但是（a）它很笨拙而且（b）现在这很好，当客户只是将所有现有数据迁移到数据库中时，但迟早它们可能实际上可以利用这个升级在字段中输入一些Unicode字符，然后我可能不会把它们拿出来。
不幸的是我无法访问数据库或应用程序以插入测试数据 - 但我假设会出现这个问题 - 而且很可能它不会很明显，即只会有一个微妙的我的应用程序没有处理输入的数据（但认为是）的问题。
那么：使用当前的ODBC驱动程序，LiveCode应用程序是否可以从nvarchar或ntext字段正确检索完整数据？
答案 0 :(得分：1)
您是否可以使用revDataFromQuery而不是更强大的revQueryDatabase？我不使用revDataFromQuery，但我的猜测是它使用了不支持UTF16的c字符串函数。
答案 1 :(得分：0)
嗯。取决于转换发生的位置。我没有必要处理这个问题，所以带着一点点盐......
如果整个unicode结果正在通过odbc驱动程序和LiveCode的db层，那么你应该能够对结果进行取消编码。看起来你正在返回双字节字符，第二个字节为零，如果它被视为单字节字符，它将使字符串空终止。正如您所指出的，当您在SQL请求中转换为varchar时，会发生这种情况。
如果转换是在odbc层或LC的db层中进行的，那么你就不幸了，直到它成为开源并且可以被重写以处理unicode。
所以我会说不要转换为varchar，尝试在检查之前对结果进行取消编码，并且你很有可能看到你期望的结果。
答案 2 :(得分：0)
所以，为了让遇到这种情况的人受益：事实证明，如果我只阅读正确的文档位，我应该想到的问题是我在简单模式下使用revDatabaseColumnNumbered -
put revDatabaseColumnNumbered(iConnID, iColNum) into tData
...但是该模式只能返回文本，这不是我们在这里的效果，而是二进制数据。所以解决方案是使用第二种模式，
get revDatabaseColumnNumbered(iConnID, iColNum, "tData")
...此时我们获取完整的Unicode数据，然后可以决定如何处理它。完全不是revQueryDatabase代码路径的错误，只是我使用revDatabaseColumnNumbered时的错误。
感谢所有试图帮助我的人！