FDQuery what risks in using variable in place of Parameter

Navigation
3

I am making a connection to fetch data inside the bank with a IN() condition, however I had difficulty implementing this between FDQuery and FireBird .

Analyzing the problem, I realized that the SQL command was reaching the database in a condition that was impossible to execute, or even accepted by FDQuery . I tried several forms of treatment and did not work.

I appealed to what I consider to be a P.O.G. creating a String variable inserts it in the middle of SQL with the data properly handled so that it is received in the database in the way that FireBird can execute. 

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??

    
asked by anonymous 08.11.2018 / 02:21

2 answers

1

We use Firebird here too, and I assure you there is no risk, because everything is pure string that will only be processed later 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;

It's the same. By parameter I find it very difficult to use IN , we only used in the WHERE clause and we all changed to string pure.

Remember that if the field ID_LOJA is varchar all items of consulta must be enclosed in double quotation marks.

    
08.11.2018 / 11:21
1

I do not see any risks in using string instead of params . But I see benefits in using parameters, especially if your system is or will someday be ATM. This is because FireDAC already change for example a date parameter for the format accepted by the connected database. If you want to continue using params , to solve the IN issue, you can use MACROS ( MacroByName ), which is a mix of string pura with params .     

08.11.2018 / 12:23
Delay in creating internal document through V9 engines Position one element over the other