The reason for the error was the sequence of the variables holding the mail-recipients (“$RECIPIENTS” and “$CCRECIPIENTS”). The last parameter to “mail” must ever be the final recipient. So all “CC”s have to go before that. The correct line is this:

If we apply a PASSWORD_VERIFY_FUNCTION to a user’s profile, we would need a little more syntax than usual to change the users’s password. A simple “ALTER USER username IDENTIFIED BY password;” for most users would not work:

This “REPLACE” can only be omitted, if the executing user has the “ALTER USER” system privilege or if a PASSWORD_VERIFY_FUNCTION is not in use. In the presence of a PASSWORD_VERIFY_FUNCTION the REPLACE can only be omitted if the user changes his/her password for the first time.

This is important to keep in mind for cases when we want the password to be set via an application. Here the application’s logic must be able to handle the above.

Edit 2014-08-27:
It took some time for me to grasp the logic behind this syntax – but now I think I got it:

As the users passwords are always stored encrypted / hashed in the database, there would be otherwise no chance for a PASSWORD_VERIFY_FUNCTION to check the new password for a minimum number of changed characters compared to the old password.

If the new password would differ in at least one single character, the hash-value of that password would be completely different to the hash of the old password – so no use for the aforementioned check. That way we could just check for “NEW_PWD != OLD_PWD”. Since there is no profile limit for a minimum number of changed password-characters, the only way to check this is in a PASSWORD_VERIFY_FUNCTION – and hence it makes sense to just request the old password ( or request the old password at all ) in case we use a PASSWORD_VERIFY_FUNCTION.

Just verified this on My Oracle Support (MOS) and found it confirmed under
“Password Verify Function Not Enforcing Difference Between Old and New Passwords” (Doc ID 816932.1)

Foreign key references/constraints are a neat thing to keep your data’s integrity. But it can be a pain if you need to delete records in a parent-table.

Unless you have identified and deleted all referencing child-records, the DB won’t let you delete the parent-records. To identify the children you need to know the foreign-key-structure put on that parent-table.

Then you can drill down by the references to the child-records and delete them first.

If your circumstances (applications, user) would allow, it would perhaps by easier to “alter” all your foreign-keys with “ON DELETE CASCADE”.
Unfortunately you can not simply modify them to get that enabled. You’ll have to drop and re-create them with “ON DELETE CASCADE”.