I'm trying to do this
INSERT INTO INSPECTIONOFFICE (INSPOFFICE_ID, INSPOFFICE_NAME, INSPOFFICE_STREET, INSPOFFICE_CITY, INSPOFFICE_STATE, INSPOFFICE_ZIPCODE, INSPOFFICE_CONTPERSONFNAME, INSPOFFICE_CONTPERSONLNAME, INSPOFFICE_CONTPERSONPHONE, INSPOFFICE_CONTPERSONEMAIL)
VALUES (12, 'InspectionOffice1', '121 Ames st', 'Omaha', 'NE', 68128, 'Brad', 'Foley', '4022853487', 'BradFoley#gmail.com');
but I get an error
Error starting at line : 22 in command -
INSERT INTO INSPECTIONOFFICE (INSPOFFICE_ID, INSPOFFICE_NAME, INSPOFFICE_STREET, INSPOFFICE_CITY, INSPOFFICE_STATE, INSPOFFICE_ZIPCODE, INSPOFFICE_CONTPERSONFNAME, INSPOFFICE_CONTPERSONLNAME, INSPOFFICE_CONTPERSONPHONE, INSPOFFICE_CONTPERSONEMAIL)
VALUES (12, 'InspectionOffice1', '121 Ames st', 'Omaha', 'NE', 68128, 'Brad', 'Foley', '4022853487', 'BradFoley#gmail.com')
Error at Command Line : 22 Column : 13
Error report -
SQL Error: ORA-04098: trigger 'JMEEK.INSPECTIONOFFICE_INSPECTIONOFF' is invalid and failed re-validation
04098. 00000 - "trigger '%s.%s' is invalid and failed re-validation"
*Cause: A trigger was attempted to be retrieved for execution and was found to be invalid. This also means that compilation/authorization failed for the trigger.
*Action: Options are to resolve the compilation/authorization errors, disable the trigger, or drop the trigger.
Any idea how to fix this?
seems you do not have permission access to the trigger JMEEK.INSPECTIONOFFICE_INSPECTIONOFF
or have some compilation problem with it...
you should take a look in the trigger.
or if you don't know what a trigger is, call a experienced job's teammate. :)
btw, if you are alone, and it don't matter too much.. you can disable / drop the trigger..
this command disable, you can enable later
ALTER TRIGGER JMEEK.INSPECTIONOFFICE_INSPECTIONOFF DISABLE;
this command drop the trigger, you will lose it forever (if you don't have a backup)
drop trigger JMEEK.INSPECTIONOFFICE_INSPECTIONOFF;
The trigger JMEEK.INSPECTIONOFFICE_INSPECTIONOFF, which I am guessing you wrote because it's in the JMEEK schema, which (again I'm guessing) seems to be yours, is invalid, meaning it has compilation errors. To find out what those errors are you should execute the query
SELECT *
FROM ALL_ERRORS
WHERE OWNER = 'JMEEK' AND
NAME = 'INSPECTIONOFFICE_INSPECTIONOFF'
ORDER BY SEQUENCE
None of us can do much else for you because we don't know what this trigger looks like. If you need to see the source code you can execute the following query:
SELECT LINE, TEXT
FROM ALL_SOURCE
WHERE OWNER = 'JMEEK' AND
NAME = 'INSPECTIONOFFICE_INSPECTIONOFF'
ORDER BY LINE
Or you can use an IDE such as Oracle's free SQL Developer product which will make all this a lot easier for you.
Related
I have a blank table for which I've set up a trigger:
CREATE OR REPLACE TRIGGER authors_bir
BEFORE INSERT ON authors
FOR EACH ROW
begin
if upper(:new.name) = 'TEST' then
raise_application_error(-20001, 'Sorry, that value is not allowed.');
end if;
end;
After executing:
insert into AUTHORS
VALUES (1, 'test', '1-Jan-1989', 'M');
Why am I getting ORA-06512 and ORA-04088 error messages in addition to the expected ORA-20001 error prompt?
ErrorMessage
Error starting at line : 5 in command -
insert into AUTHORS
VALUES (1, 'test', '1-Jan-1989', 'M')
Error report -
ORA-20001: Sorry, that value is not allowed.
ORA-06512: at "RPS.AUTHORS_BIR", line 3
ORA-04088: error during execution of trigger 'RPS.AUTHORS_BIR'
Your trigger works perfectly and ORA-06512 is part of debugging mode and tells you what line of code raised that ORA-20001 that you coded. While ORA-04088 is saying that an error has occurred in the trigger. Both error codes are GENERIC part of oracle troubleshooting report.
According to documentation:
ORA-06512: at stringline string
Cause: Backtrace message as the stack is unwound by unhandled exceptions.
Basically, this error is part of the error stack telling at which line the actual error occurred.
And documentation:
ORA-04088: error during execution of trigger 'string.string'
Cause: A runtime error occurred during execution of a trigger.
And this error is a part of the error stack telling you that error actually occurred in a trigger.
When an unhandled error occurs, error stack is always displayed. If you want to display just the error message, you could use an exception handling part so body of the trigger would look something like this:
begin
if upper(:new.name) = 'TEST' then
raise_application_error(-20001, 'Sorry, that value is not allowed.');
end if;
exception
when others then
dbms_output.put_line(sqlcode|' '|sqlerrm);
end;
I have some procedure written in Oracle. Unfortunately I can't show its code. Somewhere inside it is select where execution crashed because of absence of required data. It looks like this
select value into l_value
from config
where code = upper(p_code);
So when I call this procedure like this (in SqlDeveloper)
execute some_package.some_procedure('CODE');
it throws
Error report -
ORA-01403: no data found
ORA-06512: at "XXXXXXXXXXXXXXXXXXX", line 111
ORA-06512: at "XXXXXXXXXXXXXXXXXXX", line 111
ORA-06512: at line 1
01403. 00000 - "no data found"
*Cause: No data was found from the objects.
*Action: There was no data from the objects which may be due to end of fetch.
But when I call it like this
call some_package.some_procedure('CODE');
it crashes at the same place (as I can suggest from the result, stored in DB), but it does no throw an exception.
some_package.some_procedure('CODE') succeeded.
What happens? And why there is such difference?
NO_DATA_FOUND exception behavior is special. It is handled by default in SQL context but not in PL/SQL. In SQL no data found is not considered as an error, it happens all the time that there is no data that meets certain condition.
CALL is SQL command whereas EXEC is a shortcut for BEGIN <code> END; which is PL/SQL.
I rise DUP_VAL_ON_INDEX in SQL and I'd like to associate some custom error message with it.
Right now after executing the code
IF ___SOME_CONDITION___ THEN
RAISE DUP_VAL_ON_INDEX;
END IF
I see following message:
00001. 00000 - "unique constraint (%s.%s) violated"
How I can provide custom message to substitute these "%s"?
You wouldn't typically raise these pre-defined errors yourself. Instead, you would either let the database raise them (eg. you really have tried to insert a row that violates the unique constraint/index) or raise your own custom error (eg. raise_application_error()) and provide the necessary information there.
I have two service programs: mySrvPgm and myErr
mySrvPgm has a procedure which contains:
/free
...
exec sql INSERT INTO TABLE VALUES(:RECORD_FMT);
if sqlError() = *ON;
//handle error
endif;
...
/end-free
myErr has a procedure sqlError:
/free
exec sql GET DIAGNOSTICS CONDITION 1
:state = RETURNED_SQLSTATE;
...
/end-free
Background info: I am using XMLSERVICE to call the given procedure in mySrvPgm from PHP. I am not using a persistent connection. myErr is bound-by-reference via a binding directory used by mySrvPgm. Its activation is set to *IMMED, its activation group is set to *CALLER.
The problem: Assume there is an error on the INSERT statement in mySvrPgm. The first time sqlError() is called it will return SQLSTATE 00000 despite the error. All subsequent calls to sqlError() return the expected SQLSTATE.
A workaround: I added a procedure to myErr called initSQL:
/free
exec sql SET SCHEMA MYLIB;
/end-free
If I call initSQL() before the INSERT statement in mySrvPgm, sqlError() functions correctly. It doesn't have to be SET SCHEMA, it can be another GET DIAGNOSTICS statement. However, if it does not contain an executable SQL statement it does not help.
The question: I believe the myErr service program is activating properly and has the correct scope, but I am wondering if there is something more I need to do to activate the SQL part of it. Is there some way to set it up so SQL auto-initializes when the service program is activated, or do I have to execute an unneeded SQL statement in order to get it started?
There is some more background information available here.
Thank you for reading.
What version an release of the OS? Are you upto date on PTFs?
Honestly, seems to me that it's possibly a bug. Or the manual(s) need clarification.. I'd open a PMR.
Cannot stop and drop oracle Queue.
Following code
BEGIN
DBMS_AQADM.STOP_QUEUE (
queue_name => 'TEST_QUEUE');
DBMS_AQADM.DROP_QUEUE(
queue_name => 'TEST_QUEUE');
END;
/
produces following errors:
ERROR at line 1:
ORA-04068: existing state of packages has been discarded
ORA-04065: not executed, altered or dropped stored procedure "SYS.DBMS_ASSERT"
ORA-06508: PL/SQL: could not find program unit being called: "SYS.DBMS_ASSERT"
ORA-06512: at "SYS.DBMS_AQADM_SYS", line 3365
ORA-06512: at "SYS.DBMS_AQADM", line 167
ORA-06512: at line 5
What can be the root cause of this problem?
UPDATE:
SQL> SELECT * FROM USER_TAB_PRIVS where table_name='DBMS_ASSERT' and GRANTEE='TEST_USER'
...
GRANTEE=TEST_USER
OWNER=SYS
TABLE_NAME=DBMS_ASSERT
GRANTOR=SYS
PRIVILEGE=EXECUTE
GRANTABLE=NO
HIERARCHY=NO
SQL> SELECT * FROM USER_TAB_PRIVS where table_name='DBMS_AQADM' and GRANTEE='TEST_USER'
...
GRANTEE=TEST_USER
OWNER=SYS
TABLE_NAME=DBMS_AQADM
GRANTOR=SYSTEM
PRIVILEGE=EXECUTE
GRANTABLE=NO
HIERARCHY=NO
I’ve checked the table USER_TAB_PRIVS in a few our schemas and I can see that record with table name 'DBMS_ASSERT' exists in schema with in TEST_USER only.
User have EXECUTE privilege.
It looks to me like either the DBMS_ASSERT package doesn't exist (unlikely but I suppose possible), or the user you used to log into the database doesn't have execute rights on it. Typically PUBLIC is granted EXECUTE access to DBMS_ASSERT but perhaps it was changed at your site. Check EXECUTE permission grants on DBMS_ASSERT and DBMS_AQADM.
If you've made this call before without any problems, then the ORA-04068 error makes me think that something in the calling chain has been invalidated. Have you applied any upgrades or patches to the installation recently?
Oracle supplies a script, utlrp in $ORACLE_HOME/rdbms/admin, that will recompile all of the packages and report on any remaining invalid. Have your administrator run that (as SYS).