Like when you're moving a table that contains a list of all valid OS = user accounts in order to maintain (disable) Oracle accounts, only you = fat fingered the SQLLoader module causing all employees to have their = respective DB accounts locked and expired? Not only that, but that the = program you've written to do this from the OS explicitly sets the SID to = production because otherwise it won't know what SID to connect to when = this job is normally run via cron? And I've suddenly remembered that = while there's an "UNLOCK" clause for ALTER USER, there's no UNEXPIRE. <heavy sigh> The Response Center's gonna love me... At least I had = enough sense to use groups to segregate user's read-only Oracle accounts = from the management and app accounts. Yes, it is Beer Day. Rich Rich Jesse System/Database Administrator rich.jesse@xxxxxxxxxxxxxxxxx QuadTech, Sussex, WI USA ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------