Re: Error 32504 - solved :(

In <6jg4g5$qp7$1@godzilla.zeta.org.au> batonnet@zeta.org.au (Bryan Tonnet) writes: In case anyone's interested; >As there are several hundred users total at these sites, and each site's local >administrator has autonomy to add and delete users as required, it has become >a complete pain to continually keep the sites' password files in sync with >each other so that Informix can do its remote thang. Unfortunately, an option >like NIS is not possible. >Recently I began fiddling with SET SESSION AUTHORIZATION and discovered that >although an indivual user could not use it to change usernames, a DBA >priviledged SPL with public execute permission could. Thinking I had found >the answer, I created a 'psuedo'user at each site, and created an SPL to >SET SESSION AUTHORIZATION to this user. The 'pseudo'user was given Informix >permissions to do only what needed to be done at the remote sites. >Alas, when a session that has run SET SESSION AUTHORIZATION attempts to >remotely update a table, I get the error number I put in the Subject of this >post. The error describes how I can't do remote work on a table if I have >changed my "sensitivity level". >So, what's a "sensitivity level" and how do I change it to something I can use? >I suspect it's just trying to tell me I can't change users and do remote work >on tables, but it doesn't actually say that in the error message. From Informix support: The sensitivity level error message is in error, and is only relevant when using Informix Secure. The error message should say something like "You can't perform remote operations after using SET SESSION AUTHORIZATION". Unfortunately, pretty clear cut. Someone suggested roles to circumvent the problem, but roles are only relevant to the local Informix server, and I can't figure a way to get SET ROLE to execute remotely. I can't use a DATABASE statement to change to the remote database (inside a transaction) and CONNECT TO is not supported in 4GL. I guess it's back to disgruntled users and passwd file hacking for the moment. :( -- Bryan Tonnet batonnet@phase4.com.au