a follow-up question on permissions

Several of you (and also informix support) have verified what I suspected - that there is no way to prevent either the dba or the creator of a table from being able to update a table. Now I'm working on some work arounds and I thought I'd give you more info about my application and the types of workarounds I'm looking at. Informix databases and tables are created and deleted dynamically by my application (I don't approve of this, but the application pre-dates me being on the project and I haven't been able to change this yet). Anyway, the program that creates new databases grants dba to public because, theoretically, any user might be deleting the database (security is handled by the application). We also have another program that, within a database, creates whole sets of additional tables - some of these additional tables are exact copies of original tables and can not be updated. There is much embedded code relying on this data architecture. As a space-savings mechanism, I decided that we would change the process in that, rather than create tables that are exact copies of other tables, we would create views that select * from the base table. So we would have a situation where we have physical table tab1 and several views, say tab1a, tab1b, tab1c, etc. Now keep in mind that public is dba and even if it weren't, tab1a, tab1b and tab1c might each have a different creator. Here's the problem, even though users are not suppose to use isql, they do and we are told that we must allow them. If the user that created view tab1c unknowingly updated tab1 thru that view, the update also ripples to tab1a and tab1b, which are being used by different users. My first workaround was to change to effective user of the programs that create/delete dbs/tables by running chmod 6755 on those executable. This should have made informix think that the owner of the executable was the user at run time and that login would be the dba/creator. This did not work, apparently informix uses the real user rather than the effective. We are running att universe, so you can only change the real user if you are root. I thought of updating the system catalog tables dynamically after the db/tables are created but didn't think I'd have permission. Surprisingly, I was able to update sysusers (an informix bug?) but was not able to update systables. End of that plan. The one really non-elegant thing that will work is too silly to do. When I create the view, I could create as a join with a table that always has one row. Even the creator and dba cannot update thru that type of a view. No way I'm going to do this. Any other ideas out there ??? thanks, Warren J. Saccente Bellcore