Truncate table test_abc;
It is giving me error :
Oracle error 01426: Numeric Overflow.
Oracle version is 11g.
I agree with Alex Poole that it seems odd for a TRUNCATE to cause that error. Perhaps there is an error with a recursive SQL or PL/SQL statement that executes with
each truncate. Post the entire error message, it should include the relevant errors, objects, and line numbers.
If that doesn't help, look for any triggers that execute for each truncate. There are many potentially relevant triggering events. These are the most likely, but it's
also possible there is an INSERT, UPDATE, or DELETE trigger on an X$ table or something odd.
select *
from dba_triggers
where triggering_event like '%DDL%' or triggering_event like '%TRUNCATE%';
The objects can be viewed through DBA_SOURCE, unless they are wrapped.
Related
database : vertica
when I use insert into.....select.... statement to add data, following error occurred:
notice : error encounterred in contriant validation
error : ddl statement interferred with query plan
hint : please reissue query
This error, although it is not the actual error, is pretty self explanatory. You tried to issue an INSERT statement, but there was another DDL statement that interfered (was holding a lock on the table) at the same time and so your INSERT statement was killed.
At this point you probably won't be able to see it any more, but in the future when you see this error, take note of the time that the statement was executed, then query the v_monitor.query_requests system table to see what other DDL statements were being executed at the same time.
If this was just an ad hoc INSERT statement, then the solution is to do exactly what the Vertica notice message said, re-issue the query. If this is part of a script or application logic, then you need to handle this error accordingly and add the logic to re-issue the statement again if this error is thrown.
I noticed that Oracle SQL Developer (19.1.0.094.2042) cited a syntax error (via highlight) for a database trigger that has been enabled since 2013 (I just started), a trigger that complies without errors and fires. Oracle was just updated from 11g to 18c. Now I'm inquiring whether the order of the DML statements matters when using the "of" clause.
When I change the order of "DELETE" and "UPDATE," it compiles just the same, albeit without the error highlighting.
With syntax error:
AFTER UPDATE OR DELETE OF column_name ON table_name
FOR EACH ROW
Without syntax error:
AFTER DELETE OR UPDATE OF column_name ON table_name
FOR EACH ROW
It seems prima facie odd to use the first ordering since it seems to grammatically imply that both disjuncts apply to the "of" clause. There is no use for "DELETE OF." However, I couldn't find this question, or an explanation, anywhere, and while I saw both orderings, there were actually more instances of "UPDATE OR DELETE OF" than "DELETE OR UPDATE OF."
I'm still new to the IT industry (< 1 year), and this is my first post; I appreciate any feedback.
Yes it matters. The one which doesn't fail is in effect saying
AFTER (DELETE) OR (UPDATE OF COLUMN_NAME) ON TABLE_NAME
The one which fails is (trying) to say
AFTER (UPDATE) OR (DELETE OF COLUMN_NAME) ON TABLE_NAME
(Here the parentheses are only for purposes of clarification - using them in Real Code (tm) would also result in a syntax error).
'OF COLUMN_NAME' is only valid in conjunction with UPDATE. When associated with DELETE it's a syntax error.
If you hadn't specified a column name you could phrase it either way, e.g. as
AFTER UPDATE OR DELETE ON TABLE_NAME
or
AFTER DELETE OR UPDATE ON TABLE_NAME
Best of luck.
EDIT
To quote Popeye, "Well, blow me down!!!".
I'm surprised, but Oracle will actually accept the OF column_name after either UPDATE or DELETE, and apparently it fires correctly in either case, treating it as if the trigger was written for UPDATE OF COLUMN_NAME even if the UPDATE does not immediately precede OF COLUMN_NAME.
dbfiddle here
So apparently the error message is solely being produced by SQL Developer, and the database happily accepts it where and when ever.
I learn somethin' new ever' day. :-)
I see no required order defined in the syntax diagram, so I'm thinking you might have found a bug in sqldeveloper.
I tried to update the field "contract_id" in the table "contract_scan_image".
However, the update was failed and an error "746: Field contract_id and type of contract_scan_image cannot be updated!" was shown.
My SQL command is:
update contract_scan_image
set contract_id = '14864730'
where contract_id = '1486473'
and type = 'RM'
and account = '00193400944'
Does anyone know what happened and how to fix it?
Error message -746 is for user-defined errors. It typically is used in stored procedures in a RAISE EXCEPTION statement:
RAISE EXCEPTION -746, 0, "Field contract_id and type of contract_scan_image cannot be updated!"
The actual message text for error -746 in the message files is:
%s
That is, it prints the string it is given as a string.
So, you are going to need to track down the triggers and stored procedures invoked by those triggers on the contract_scan_image table, and deduce from where the error is generated what you are doing wrong. Superficially, though, it appears that you are not allowed to alter the contract ID, yet that is what you are trying to do.
First things first, I would take a look at a list of Reserved words in SQL - https://drupal.org/node/141051
I would get in the habit of surrounding fields with `` See below:
update contract_scan_image
set `contract_id` = '14864730'
where `contract_id` = '1486473'
and `type` = 'RM'
and `account` = '00193400944'
** Note - type is a reserved word
The error is caused by something being triggered. Then no table can be modified by UPDATE command.
Finally I deleted the record I want to update. Then added back the modified record.
I copy the error description here from the net for reference.
BTW, I asked my supervisor and he said he did trigger something to cause this. (He didn't tell me how to un-trigger it...)
-746
THE SQL STATEMENT IN FUNCTION, TRIGGER, OR IN STORED PROCEDURE name VIOLATES THE NESTING SQL RESTRICTION
Explanation
If a table is being modified (by INSERT, DELETE, UPDATE, or MERGE), the table can not be accessed by the lower level nesting SQL statement.
If any table is being accessed by a SELECT statement, no table can be modified (by INSERT, DELETE, UPDATE, or MERGE) in any lower level nesting SQL statement.
System action
The SELECT, INSERT, DELETE, UPDATE or MERGE SQL statement failed.
Programmer response
Remove the failing statement from the named function, trigger or the stored procedure.
SQLSTATE
57053
Can the dbms_errlog function be used for SELECT queries?
I earlier encountered an error where Oracle is throwing an ORA-0722, i was trying to identify which column and possibly, row of a PL/SQL statement that was throwing that error. However i found out that dbms_errlog is native to only Oracle 10g and above.
In the case also, what alternatives do i have if i am using Oracle 9i?
DBMS_ERRLOG ist not a function, it is a PL/SQL package. It contains one procedure that creates an error table. To log errors to this error, you need to specify the "log errors" clause to your DML statements. From this description it should be obvious that this is tightly integrated with the transaction layer.
One way to reproduce similar behavior in earlier releases is to
Create your own error table
Create a PL/SQL procedure that inserts into that error table. To
make sure that the log is written in case of errors this procedure has to use
autonomous transactions.
The calls to log errors have to be explicitly added to the
corresponding exception handlers.
Are there any cases where an INSERT in SQL (specifically Oracle-PL/SQL) can fail without an exception being thrown? I'm seeing checks in code after INSERT where it verifies that SQL%ROWCOUNT = 1 ELSE it raises its own user-defined exception. I don't see how that can ever happen.
It can't fail without an exception, no. Probably the developer who wrote the code didn't know that.
An after statement trigger could conceivably delete the row just inserted. And of course an INSERT...SELECT might find no rows to insert, and so would result in SQL%ROWCOUNT = 0.
In addition to the trigger-based issue #mcabral mentioned, you could have an insert that is successful but inserts other than 1 row. For example, the insert into blah(col1) select col2 from foo style of insert.
As #TonyAndrews and #GinoA mentioned, there are several ways an INSERT could return something other than exactly one row (triggers, INSERT INTO tablename SELECT... syntax).
But the bigger issue is that you're in PL/SQL. As such, the SQL%ROWCOUNT value can be used as a condition to determine the program execution flow including issuing COMMIT or ROLLBACK statements.
Even with just raising a user-defined exception, the calling PL/SQL block can handle the exception itself.
EDIT: Someone should modify the question title to indicate PL/SQL (as indicated in the question itself), since that's not the same thing as SQL scope the title suggests.