如何避免问号字符的 ODBC 参数化？在文字和评论中？

Posted 2023-03-27

【中文标题】如何避免问号字符的 ODBC 参数化？在文字和评论中？

【英文标题】：How to avoid ODBC parameterization for the question mark character ? within literals and comments?

【发布时间】：2010-07-28 00:04:16

【问题描述】：

我遇到了一个问题，其中有问号字符“？”在我的 cmets 内的 SQL 脚本中导致问题。当我使用 Visual FoxPro SQLEXEC 函数通过 ODBC 连接运行这些语句时，这些字符被视为参数和 VFP 值提示。

在使用 SQLEXEC 时，我有哪些选项可以处理 cmets 中的问号字符？我希望我可能会在某些情况下关闭参数化，或者在将字符串作为命令传递之前如何转义这些字符。到目前为止，我还没有找到这种解决方案的任何证据，所以看起来我可能不得不删除所有不受欢迎的 cmets，因为它们通常是为存储过程创建语句，我们希望保留这些 cmets。我希望有人可能有一个比完全去除 cmets 更令人满意的解决方案。

【参考方案1】：

看来是known issueSQLEXEC在SQL命令中遇到问号字符时没有考虑cmets？通常在 ODBC 中表示参数，在 VFP 中也是如此。

只是一个警告 - VFP 的解析器会 捕获 SQL 中的任何问号 字符串，即使它在 SQL 中 注释（即在以 -- 或括在 /* */) 之间，如果没有，则会出错 那里可以是一个变量。如果它 可以是一个变量，但你没有 它在运行时定义，你会得到一个丑陋的 输入框输入它。更糟糕的是，您的用户 明白了。

所以要小心。 ——德拉甘·内德尔科维奇

【参考方案2】：

您是否尝试过将其替换为 ascii 代码？类似：'+chr(63)+'

【讨论】：

嗯，这对于诸如“where mycolumn = 'what' + char(63)”之类的文字来说是一个可用的解决方法，但因为问题似乎源于 cmets 从 VFP 连接 chr(63)在表达式中只会产生包含传递给 SQLEXEC 的问号的相同字符串。所以基本上这与将问号保留在文字中是一样的。