Paul,
You can do dynamic sql using the JDBC adapter. wmDB is legacy technology and the JDBC adapter is where webMethods is focusing their development efforts. So using the JDBC adapter is the preferred approach.
Assuming Oracle…
Create a Dynamic SQL adapter service. In the dynamic sql field, place the SQL you want to dynamically substitute inside ${}. For example:
SELECT empno,ename,job from ${table} WHERE ${pred}
table and pred become service inputs automatically. (Don’t try to specify them as input fields.
You will need to supply appropriate output fields, 1 for each column in your select list. So if you are used to doing dynamic sql in a 3gl, it’s not quite that “dynamic”. This is a compromise imposed so that when you add the invoke step for your adapter service, you have predefined output fields that you can map from.
Although the number of select list items must be predefined, you could dynamically choose what to select at runtime.
You can supply input fields (i.e. Bind Variables) and these will also become part of the service input. Place a question mark in the SQL text or inside the text you are substituting with a ${expression}. As with other adapter services, the order of the input fields you declare corresponds to the order in which the ? symbols are encountered in the final SQL statement. Remember that in Oracle, bind variables only help you when the SQL statement you are submitting exactly matches a previous SQL statement previously submitted. Otherwise, the SQL statement will still have to be re-parsed. If you are doing dynamic sql, this is probably not likely. You should only consider bind variables for short running queries.
If you are going to be doing a long-running query, it would be better to avoid bind variables because they prevent the optimizer from using column histogram statistics in generating a query plan.
#Adapters-and-E-Standards#Integration-Server-and-ESB#webMethods