432699_es-ES

liliconcom

Proporcionar un mecanismo para consultas SQL parametrizadas

Las bibliotecas ODBC suelen ofrecer la posibilidad de crear consultas parametrizadas que pasan la consulta y los parámetros a la base de datos por separado. Esto básicamente elimina el riesgo de ataques de inyección SQL, pero también es muy conveniente desde el punto de vista de la programación. Debido a que JMP tiene consultas ODBC, también debería tener consultas parametrizadas para que pueda hacer lo siguiente:

Execute SQL(database, 
    "Select * from Employees where Name like ? and Status=?",
    "BobList", 
    {"Bob", "Active"}
);

Consultas parametrizadas de pyodbc:

https://github.com/mkleehammer/pyodbc/wiki/Getting-started#parameters

Las consultas parametrizadas del ecosistema .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

Automatización y scriptingRe: Proporcionar un mecanismo para consultas SQL parametrizadas

Creo que podría implementar esto usando consultas con nombre: Create Named Query() y Execute Named Query(). En esencia, estas funciones usarían las funciones ODBC SQLPrepare(), SQLBindParameter() y SQLExecute(). La función Create Named Query() tomaría la declaración SQL y los parámetros. Devolvería un objeto de consulta con nombre. La función Execute Named Query() tomaría el objeto de conexión de base de datos, el objeto de consulta con nombre y los valores de los parámetros como entradas y devolvería los resultados SQL como una tabla de datos (si es necesario). El objeto de conexión de base de datos podría ser una entrada de la función de creación en lugar de la función de ejecución. El beneficio de este enfoque es que la creación puede ocurrir en la inicialización del script dejando la parte de ejecución separada, lo que probablemente será más eficiente.

Re: Proporcionar un mecanismo para consultas SQL parametrizadas

También me gustaría tener algo similar, al menos para poder pasar los argumentos de conexión y consulta SQL por separado y así facilitar las pruebas unitarias. Por ejemplo, al probar una función que contiene una consulta SQL, la conexión podría intercambiarse fácilmente por una tabla JMP local.