パラメータ化されたSQLクエリのメカニズムを提供するODBC ライブラリは通常、クエリとパラメータを別々にデータベースに渡すパラメータ化されたクエリを作成する機能を提供します。これにより、基本的に SQL インジェクション攻撃のリスクが排除されますが、プログラミングの観点からも非常に便利です。JMP には ODBC クエリがあるため、パラメータ化されたクエリも用意されているので、次の操作を実行できます。
Execute SQL(database,
"Select * from Employees where Name like ? and Status=?",
"BobList",
{"Bob", "Active"}
);pyodbc のパラメータ化されたクエリ:
https://github.com/mkleehammer/pyodbc/wiki/Getting-started#parameters
.NET エコシステムのパラメーター化されたクエリ:
https://docs.microsoft.com/en-us/dotnet/api/system.data.odbc.odbccommand.parameters?redirectedfrom=MSDN&view=dotnet-plat-ext-5.0#System_Data_Odbc_OdbcCommand_Parameters
自動化とスクリプトRe: パラメータ化された SQL クエリのメカニズムを提供する名前付きクエリを使用してこれを実装できると思います: Create Named Query() および Execute Named Query()。内部的には、これらの関数は ODBC SQLPrepare()、SQLBindParameter()、および SQLExecute() 関数を使用します。Create Named Query() 関数は、SQL ステートメントとパラメータを受け取ります。名前付きクエリ オブジェクトを返します。Execute Named Query() は、データベース接続オブジェクト、名前付きクエリ オブジェクト、およびパラメータ値を入力として受け取り、SQL 結果をデータ テーブルとして返します (必要な場合)。データベース接続オブジェクトは、execute 関数ではなく、create 関数の入力にすることができます。このアプローチの利点は、スクリプトの初期化時に作成が行われ、実行部分が別々になるため、おそらくより効率的になることです。
Re: パラメータ化されたSQLクエリのメカニズムを提供する私も同じような機能が欲しいと思っています。少なくとも、SQL接続とクエリ引数を別々に渡せるようにして、ユニットテスト関数のテストを容易にしたいのです。例えば、SQLクエリを含む関数をテストする場合、接続をローカルのJMPテーブルに簡単に置き換えることができます。
