Re: Using host variable in embedded sql

... besides the point, that the problem of the OP is not to be solved with static SQL...
The important diffrence between static sql and dynamic sql is not runtime performance (with an appropriate index and application design, it would be hard to make the performance diffrences measurable). Comparing static sql versus dynamic sql you will find pros and cons and the the very important benefit of static sql is, that the compiler does more work for the programmer. All sql statements are verified at compiletime and all assignments of host variables to sql variables are checked and the compiler ensures type compatibility.
On the other hand dynamic sql wins by far in the perspective of programmer performance, if you use the full flexibility of dynamic SQL, as Brad is describing it. But if you are using dynamic sql, you should ensure that your index design is appropriate to your use cases and your application design should be appropriate. You would have to strictly ensure type compatibility (use of parameter markers could help a lot) and some caching of prepared statements could improve the speed up to the level of static sql (BTW: the database does a lot of this for you). Some caching at application level in a fine grained modularized application would do more for better performance as lots of headaches about CQE and SQE, OPNCLO and some compiler settings (I'm using all default settings and don't worry about which part of the optimizer has to do the work for me, this might change tomorrow anyway)!
Having a look to some applications and installations, you will find rather often lots of weaknesses in database and index design (application design as well), loosing all the performance one could win by some OPNCLO settings and replacing simple sql constructs with more complicated constructs.

D*B