而且我猜你不想编写一个解析器来管理 Jet SQL 和 T-SQL 之间的翻译......
我们开发的一个解决方案(是的,我们有一个类似的问题要解决)是定义一些我们在元 SQL 语法中使用的“伪元语言”,我们有一种从这种元语言到 Jet SQL 的翻译器或 T-SQL。
例子:
myQuery = "SELECT @MyCoalesceFunction@([Amount], 0) FROM PaymentsDue;"
myQuery = convertFromMeta(myQuery,"T-SQL")
will give
"SELECT COALESCE([Amount], 0) FROM PaymentsDue;"
myQuery = convertFromMeta(myQuery,"JET-SQL")
will give
"SELECT NZ([Amount], 0) FROM PaymentsDue;"
相同的策略可用于通配符和定界符:
myQuery = "SELECT [Amount] FROM PaymentsDue WHERE id_client LIKE @CarSep@ABC@MyWildCard@@CarSep@"
myQuery = convertFromMeta(myQuery,"T-SQL")
will give
"SELECT [Amount] FROM PaymentsDue WHERE id_client LIKE 'ABC%'"
myQuery = convertFromMeta(myQuery,"JET-SQL")
will give
"SELECT [Amount] FROM PaymentsDue WHERE id_client LIKE "ABC%""
我知道它不是很好,但它非常高效和干净。要点是:
- 我们不是在 Jet 和 T-SQL 之间进行翻译,而是从“元语法”进行翻译。它使事情变得容易得多
- 当函数的参数数量不同时,或者参数的传递顺序不同时,应该非常小心。还是可以做到的...
- 我们的元语法依赖于这样一个事实,即相应的字符串(如'@MyWildCard@'或'@CarSep@')是特定于我们的语法的,不能用作数据值(否则我们将不得不管理一些'meta-注射的风险!...)