I am generating a query string dynamically which i want to execute only if it is avalid query (valid syntax). Otherwise i want to skip that query and continue pl sql execution. How can it be done?
Nest that query execution with another BEGIN..EXCEPTION..END; .In exception, handle "WHEN OTHERS". In case there is any syntax error, it will be caught in exception block and next line of your logic in pl/sql execution will be moved on to.
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 am trying to get the SQL query to be returned from a database call, when the query fails to execute and the return cursor has a failure state. This query string will be used for logging purposes.
One way to do this is to hold a variable that contains the SQL query as a string, and then wrap each query in the PL/SQL block with the exception handler and if an exception arises, return the query string with the failure status to the UI component.
Is there a better way to do this? Does Oracle exception object or any other package support this feature?
This question seems like a duplicate for the thread: Obtain the Query/CommandText that caused a SQLException
However, I did not find a solution to the problem in that thread, and I would like to know if there are any new packages supported by Oracle that gives us the query string that caused the exception to occur.
When you are calling the database from an external language (Java, C#) you can probably do it, by implementing your own JDBC (or whatever) driver.
You would do so by delegating the real world to a normal driver, but whenever a statement is sent to the database you remember the statement and if causes an exception you create a new exception which also includes the sql statement (and possibly bind variables).
Note that this will only give you your statement. If you execute a stored procedure or cause a trigger to fire which in turn fails you only get the original statement not the one that actually failed.
I recieve SQLITE_CORRUPT error for the database being corrupt.
wrong # of entries in index sqlite_autoindex_Settings_1
In my code I have a try/finally clause in which I always try to always sqlite3_finalize my statements.
Apparently on a corrupted database trying to finalize the statement raises again SQLITE_CORRUPT.
Question: Should I finalize my statements if the database is reported to be corrupted?
before sqlite3_finalize or after every sqlite3_step use sqlite3_reset.
The sqlite3_reset(S) interface resets the prepared statement S back to the beginning of its program.
check whether you have sqlite3_reset after every sqlite3_step because this is one case that causes database to be corrupt. after preparing a statement with sqlite3_prepare and executing it with sqlite3_step,you need to always reset it with sqlite3_reset.
The sqlite3_reset(S) interface resets the prepared statement S back
to the beginning of its program.
before sqlite3_finalize or after every sqlite3_step use sqlite3_reset.
hope this solves your problem...!!!
I have a stored procedure which is the first step in an SQL Job. The SP compares dates in 2 tables, if they equal then the SQL job can continue, but if they are not I need to return value from the SP that causes the SQL Job to trigger it's on failure action.
What is the best way to do this? Is it with an RAISERROR statement or just return a value like -99?
Seems such an obvious question, but I've never thought about it before until now.
Whichever way you want. You can use a try/catch and raiserror. That can allow you to write the error to the event log as well if desired.
Typically, I'd just use an IF statement that does a return and then proceed with the rest of the code otherwise.
I think it's a matter of preference/requirements, though. Either will get the job done.
In my opinion the best practice approaches are:
a function that returns a bit 1/0 (True/False)
stored proc output parameter
Proc return values are meant to be used to test the success or failure of the proc itself, usually 0 for success and some other error number when there is an error
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.