In addition to what Holger said, CustomSQL allows you to pass some pieces of the query as input (mostly, WHERE-clause values) but everything else about the query must be fully-defined. DynamicSQL, on the other hand, allows you to make any part of the query variable. You could even make the entire query a variable if you wanted (not saying you should, just saying you could).
For example, this is valid for DynamicSQL:
SELECT VALUE FROM ${myTable} WHERE KEY = ${myKey}
But this would not be valid for CustomSQL:
SELECT VALUE FROM ? WHERE KEY = ?
You may then be thinking: DynamicSQL is more flexible and powerful so why use CustomSQL?
CustomSQL is backed by a java.sql.PreparedStatement, and therefore, it can take full advantage of a PreparedStatement’s performance improvements over a regular Statement, such as pre-compilation and optimization. In other words, CustomSQL will typically outperform DynamicSQL. Additionally, security experts frown upon the use of DynamicSQL due to the potential for SQL injection.
Personally, I try to use SelectSQL over CustomSQL and CustomSQL over DynamicSQL. If I find myself in a situation where DynamicSQL is the only viable option, then that typically tells me that a better alternative probably exists (e.g. using a stored procedure instead).
Percio
#webMethods#Integration-Server-and-ESB#Adapters-and-E-Standards