Hello Debasis,
Let me just add that EncodeSQL can also help prevent SQL injection in SQL string literals. It escapes the single quotes, which guarantees that an end-user cannot close the starting single quote and then add more SQL afterwards. But for this to work, you must enclose the @param in single quotes.
Hopefully an example will make this clear.
Suppose that a malicious end-user enters the following input to try to close the current SQL clause and then delete all the records of an entity:
''; DELETE FROM {entity};
After you run this input string through SqlEncode(), the two single quotes are escaped and it becomes:
''''; DELETE FROM {entity};
So far so good,
Now, if in your SQL you don't enclose your parameter in single quotes:
SELECT {entity}.* FROM {entity} WHERE {entity}.[textattribute] like @parameter
...then the SQL query sent to the database will still allow the SQL injection:
SELECT {entity}.* FROM {entity} WHERE {entity}.[textattribute] like ''''; DELETE FROM {entity};
To fix this and ensure that no SQL injection is possible, you must enclose in single quotes the parameter that will be substituted by the string input from the end-user, like this:
SELECT {entity}.* FROM {entity} WHERE {entity}.[textattribute] like '@parameter'
Now, when the parameter is substituted, it will look like:
SELECT {entity}.* FROM {entity} WHERE {entity}.[textattribute] like '''''; DELETE FROM {entity};'
As you can see, as long as you enclose the string parameter in single quotes and you also use the EncodeSql() built-in function, it is now impossible for an end-user to inject SQL.
We will make this more explicit in the documentation very soon, thank you Debasis and also to Eduardo for pointing this out.