432699_fr-FR

liliconcom

Fournir un mécanisme pour les requêtes SQL paramétrées

Les bibliothèques ODBC offrent généralement la possibilité de créer des requêtes paramétrées qui transmettent la requête et les paramètres à la base de données séparément. Cela élimine essentiellement le risque d'attaques par injection SQL, mais est également très pratique du point de vue de la programmation. Étant donné que JMP dispose de requêtes ODBC, il doit également disposer de requêtes paramétrées afin que vous puissiez effectuer les opérations suivantes :

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

Requêtes paramétrées de pyodbc :

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

Les requêtes paramétrées de l'écosystème .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

Automatisation et scriptsRe: Fournir un mécanisme pour les requêtes SQL paramétrées

Je pense que vous pourriez implémenter cela en utilisant des requêtes nommées : Create Named Query() et Execute Named Query(). Sous le capot, ces fonctions utiliseraient les fonctions ODBC SQLPrepare(), SQLBindParameter() et SQLExecute(). La fonction Create Named Query() prendrait l'instruction SQL et les paramètres. Elle renverrait un objet de requête nommé. La fonction Execute Named Query() prendrait l'objet de connexion à la base de données, l'objet de requête nommé et les valeurs des paramètres comme entrées et renverrait les résultats SQL sous forme de table de données (si nécessaire). L'objet de connexion à la base de données pourrait être une entrée de la fonction create au lieu de la fonction execute. L'avantage de cette approche est que la création peut se produire lors de l'initialisation du script, laissant la partie d'exécution séparée, ce qui sera probablement plus efficace.

Re : Fournir un mécanisme pour les requêtes SQL paramétrées

J'aimerais également disposer d'une solution similaire, permettant au moins de transmettre séparément les arguments de connexion et de requête SQL afin de simplifier les tests unitaires. Par exemple, lors du test d'une fonction contenant une requête SQL, la connexion pourrait facilement être remplacée par une table JMP locale.