Overcoming SPL limitations

Our project aim at building a document retreival system based on VB clients talking ODBC against Informix Online 7.24 on HP/UX. One user requirement that currently has us stumped is the requirement of query logging, every query posed at certain (not very many) tables has to be logged. One solution would have been to wrap the query in an SP by dynmically building and stating it inside the SP, but no, no dynamic SQL. Auditing is not really an option either since we don't need to know each *row* read, just the query. Some assumptions can be made about the queries that have to be logged; * The query is towards single tables only * All the fields in the where clause are character fields * None, one or more filter values can be entered for each selection field. * The constraints have to either all ANDed toghter or all ORed together, no mixes between AND and OR will be done. This has led us to one possible solution. That is to use a Stored Procedure taking all of the selection fields as parameters. Inside the SP a static query would be performed and the result returned from the SP (as well as being logged). The problem with this is when the user don't want to use all selection fields when stating a query. Take for example a table <table1> with fields <field1>, <field2> and <field3>. If the user wanted to perform the query; select * from table1 where field1 matches 'A*' What would really be queried for from inside the SP would have to be ( in order to cater for all possible combinations of field1, field2 and field3 filter values); select * from table1 where field1 matches 'A*' and field2 matches '*' and field3 matches '*' My question is this, is the optimizer smart enough to recognize that this query can be simplified to the first one and use an index on field1 instead of doing a sequential scan cause of the superflous '*' constraints for the other two columns? Not that the above example is only valid for AND queries, for OR queries the '*' constraints would have to be replaced with <any impossible value> just to not get any matches, this solution reeks of Y2K design thinking. I hate it, but what to do without dynamic SQL.... Thanks! /Ola