Csnnot send email thru UTL_SMTP (PL-SQL)

Question

If I try to send an email thru SQL it will work, but If i convert it to a PROCEDURE and then execute it with "EXECUTE PD_EMAIL('TEST','TEST'); It will give me the same error:
ORA-24247: network access denied by access control list (ACL)
Please help, this is ORACLE STANDARD EDITION 11G R2
The store procedure is as follows:
Create or Replace Procedure Pd_Email (Gv_Subject VARCHAR2, Gv_Body VARCHAR2) Is
Lv_From VARCHAR2(80) := '[email protected]';
Lv_To VARCHAR2(500) := '[email protected]';
Lv_Host VARCHAR2(30) := 'mail.myhost.com';
Lv_Conn Utl_smtp.Connection;
BEGIN
Lv_Conn := utl_smtp.Open_Connection(Lv_Host, 25);
utl_smtp.Helo(Lv_Conn, Lv_Host);
utl_smtp.Mail(Lv_Conn, Lv_From);
utl_smtp.Rcpt(Lv_Conn, Lv_To);
utl_smtp.Data(Lv_Conn,
'Date: ' || to_char(sysdate, 'Dy, DD Mon YYYY hh24:mi:ss') ||chr(13)||chr(10)||
'From: ' ||Lv_From ||chr(13)||chr(10)||
'Subject: '||Gv_Subject||chr(13)||chr(10)||
'To: ' || Lv_To||chr(13)||chr(10));
utl_smtp.Quit(Lv_Conn);
EXCEPTION
WHEN utl_smtp.Transient_Error OR utl_smtp.Permanent_Error then
raise_application_error(-20000, 'Email Error: '||sqlerrm);
END
Your help with me be greatly appreciated it.

Answer 1

Panamanian wrote:
Ok, since it does work in SQL, but not in a table trigger (if inserting). What should I check? or what sql statement should I run? for testing purposes?It cannot work in SQL as the SQL language does not support defining and using tcp sockets. PL/SQL is needed for that.
PL/SQL code is also what is used to define a trigger. So assuming the same schema is used, that PL/SQL code will be executed in the same environment irrespective of the call being via a trigger or via a normal database call.
That aside - sending e-mails from triggers is a terrible idea. A trigger is NOT intended to be used for something like that.
The transaction can be rolled back. The e-mail send cannot be undone - and en e-mail would have been send reporting on changes that never happened in the database.
The same trigger can fire twice for the very same row and transaction under special circumstances in Oracle. Thus 2 e-mails reporting the very same change... a change that can still be rolled back. How does that make sense?
The trigger can choke on mail errors. What then? Fail a perfectly valid business transaction that meets all consistency and validation rules, because the mail server is down, or there is a network problem or something?
That is not how robust applications are designed and written.