Auditing of queries

We are using online 7.24 on some version of HP/UX with VB5.0 clients through Intersolv ODBC 3.01 and have just recently in our project encountered a serious issue. The problem is that the requirements state that all user made queries against the server have to be audited, facilities for system managers to easily browse and analyse the resulting logs will also have to be implemented. So, the options I have found so far (and promptly rejected) are; 1) Initiate the auditing from the client application. No good since we are using ODBC. Short of performing some arcane magic upon ODBC or I-Connect I can se no way of stopping users using Access or any other ODBC-compliant client application and thereby bypassing the auditing. 2) Use the Informix auditing facility. Probably not feasible. As far as I know there is no way of auditing anything other than each and every row read, which would, I guess, impact performance quite severely. Apart from the hassle of having to deal with the audit files and loading them into another database. 3) Filter all queries through SPs and handle the auditing manually on the database server. Almost, but not quite. I cried when I found out there is no such thing as dynamic SQL in Informix SPL. The client application relies quite heavily on ad-hoc sql, though most of it can be restricted to quite simple queries against single tables. Nevertheless, I see no easy way (save extreme user dis-satisfaction) to retain the required functionality using static SPs. So, here I stand, with no real options. The problem is, I (like so many before me) would like to have a SP were I could pass in a variable amount of parameters used for building a query. I don't know if any new features in 7.3 would be able to help me in this? The SPs would be automatically created from code, so one (extremely ugly) way could be to restrict queries on a table to relatively few fields and then autocreate one SP with different parameters for each permutation of user selected query (i.e one for the combination 'name-areacode', one for the combination 'phone-areacode' and so on). From the client side this would not be a problem since the user should only use the client application against the database. Creationwise its not a proble either, since they would be autogenerated. The main problem I can see (apart from a damaged ego designwise) would be that the server would be loaded with about a hundred almost similar SPs. Might this be a performance problem? Thanks for any help! /Ola