そして、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-注射の危険!...)