C++ Builder 10.2.3搭配Interbase 2017运行时参数化创建用户触发动态SQL错误

报错根因 #

• Interbase 引擎对 CREATE USER 这类安全管理类DDL的Dynamic SQL解析有内置限制：这类语句不支持任何服务端侧的绑定参数（占位符传值）机制，所有需要传入的字面值（密码、名、姓）在服务器端解析时必须是完整的合法字符串字面量。
• 你使用的TIBQuery、TIBSQL组件的参数替换逻辑，仅适配SELECT/INSERT/UPDATE/DELETE这类标准DML的参数解析规则。遇到安全类DDL语句时，组件不会主动把SQL里的:参数名占位符替换为实际赋值，只会把带?占位符的原生SQL直接发送给数据库引擎，引擎解析到问号位置时自然抛出Token unknown错误，和你当前遇到的报错栈完全匹配。
• 存储过程方案行不通是Interbase的内置规则：存储过程的执行上下文不允许调用CREATE开头的DDL语句，和组件配置无关。

具体实现方案 #

核心逻辑是绕开组件的自动参数绑定流程，手动在客户端完成字符集转换和SQL值拼接，既保留MBCS到UTF8的正确转译能力，又符合Interbase对CREATE USER语句的解析规则：

1. 固定结构拼接：因为你已经明确用户名不支持MBCS，本来就需要运行时替换，直接把用户名部分按原有逻辑拼接即可，这部分不需要参数绑定。
2. 字符集转码处理：针对原来打算用参数传值的密码、名、姓三个字段，不要走组件的Parameters赋值流程：
   • 直接通过当前已连接的TIBConnection组件，调用其内置的字符集转换接口，把传入的中文、日文等MBCS字符串，按照连接配置的UTF8字符集完成编码转换，和DML参数传值走完全一致的转换链路。
   • 对转换完成的字符串做SQL字面量转义：把字符串中出现的单引号'全部替换为两个连续单引号''，避免语法错误和注入风险。
3. 执行操作：把转义完成的字符串值手动拼接到完整的CREATE USER语句中，将拼接后的纯文本SQL整体赋值给Query组件的SQL属性后直接执行。

效果说明 #

这个方案可以从根源上解决两个核心问题：

• 彻底消除Token unknown报错：发送给引擎的SQL是完全符合CREATE USER语法规则的完整语句，没有占位符，不会触发解析错误。
• 彻底解决MBCS转译问题：你之前直接拼普通字符串出现的备份、恢复时字符集转译失败问题，本质是C++ Builder默认把MBCS字符串按本地系统代码页转UTF8时没有和数据库连接的字符集配置对齐。通过连接组件内置接口完成转码后，最终的字符串编码逻辑和日常DML参数传值的转译链路完全一致，不会出现编码不匹配的问题。

内容的提问来源于stack exchange，提问作者Louis