Fdquery what risks to use variable instead of Parameter

Asked

Viewed 251 times

3

I’m making a connection to search for data inside the bank on one condition IN(), but I had trouble implementing it between FDQuery and the Firebird.

Analyzing the problem I realized that command SQL was arriving at the bank in a condition that was impossible to execute, or was not accepted by FDQuery. I tried several forms of treatment and it didn’t work.

Then I appealed to what I consider a P.O.G. by creating a variable String I inserted her in the middle of SQL with the data properly processed so that it is received in the bank in the form that the Firebird can perform.

FDconsult.SQL.Add('SELECT * FROM PED1A WHERE ID_LOJA IN (');
FDconsult.SQL.Add(consulta);
FDconsult.SQL.Add(')');
FDconsult.Open;

What risks do I offer my application by doing this type of P.O.G.?

delphi firebird firedac

  • Depends, how you get the contents of the variable consulta? You can put the way you were doing and how you were getting on the bench?

  • For reasons of logic they would not have problems, but depending on the database used can lose a little in a matter of performance. I don’t know how Firebird treats this case, but in certain banks, when the query is executed with parameters the bank already saves the execution plan and the next time the query is executed it doesn’t need to be done again.

2 answers

1


We use Firebird here too, and I assure you that there is no risk, because everything is pure string that only later will be processed by the database.

FDconsult.SQL.Clear;{Dependendo do componente é ..SQL.SelectSql.Clear}
FDconsult.SQL.Add('SELECT * FROM PED1A WHERE ID_LOJA IN (' + consulta + ')');
FDconsult.Open;

Anyway. By parameter I find it difficult to use the IN, we used only in the clause WHERE and exchange them all for string pure.

Remembering that if the field ID_LOJA for sweep all items of consulta must be in double quotes.

  • consulta := 'SomeValue); DROP DATABASE dbName;'??

  • 1

    @Sami, in this case there will give sql error, however he is talking about riscos and not security holes, because in the same way, the parameter is a string too, another detail is that consulta would be items that it feeds internally to pass as "parameter" for SQL execution. Now, who allows the query user to perform a DROP the failure is not in the execution, but in the permission.

1

I see no risk in using string in place of params.
But I see benefits in using parameters, especially if your system is or someday will be ATM.
This due to the FireDAC already change for example a date parameter to the format accepted by the connected database.
If you wish to continue using params, to resolve the issue of IN, you can use the MACROS (MacroByName), which is a mix of string pura with params.

Browser other questions tagged delphi firebird firedac

You are not signed in. Login or sign up in order to post.