Where can I find Full list of all Predefined ORACLE PL/SQL Exceptions?
I have looked at that SQLCODE:-942 and SQLCODE:-02289 are exception code for sequence and table not existed. but whatever I cannot find any official document to explain the above two error code. so question is are these oracle Predefined exceptions? because I want to use the two error code to catch this two type exceptions.
You used the term 'exceptions', but it looks like you're asking about error code values, and specifically SQLCODEs. I'll try to answer both questions. :-)
To find the pre-defined exceptions defined in the database you can look in the package SYS.STANDARD. This is where the standard exceptions, such as NO_DATA_FOUND and TOO_MANY_ROWS, are defined. This is a good place to look if you're interested in trapping a specific SQLCODE as it might save you having to define a custom exception and initializing it with PRAGMA EXCEPTION_INIT.
To find a complete list of error code values, including SQLCODEs, compiler errors, etc, you should look in the version of the Oracle Database Error Messages manual for the database version you're using. In his reply above, #Mat gives a reference to the 11.1 manual. The 11.2 manual can be found here.
Share and enjoy.
The closest thing I could find is a 10g PDF. The only error codes list I could find for 11g is an HTML document. It's totally weird to me that neither list includes the ORA-00942 code, although it's pretty self explanatory.
http://docs.oracle.com/cd/B19306_01/appdev.102/b14261.pdf , this is the Oracle database PL/SQL Language reference manual, look for predefined PL/SQL exceptions..
Related
I'd like to mark some SQL Server tables, columns, stored procedures and functions as deprecated. Something like pragma in Oracle Mark PLSQL procedure/function as deprecated
I can't remove them right away because it would break a lot of things in our legacy system. Because there are a lot of objects with similar or misleading names, it's common for a member of the team to utilize them inadvertedly. If existed something that would indicate visually that an object should not be used anymore, it would be perfect!
I'm looking for something like the IDE intellisense shows deprecation for common programming languages like Java as in this image:
You could perhaps use RAISERROR to print a warning message that a procedure is deprecated.
RAISERROR('This procedure is deprecated.', 1, 0);
If you use a low severity for the error then it shouldn't affect code execution, however it would display a message to other developers who are calling the procedure.
I am a user of Vensim P.L.E. 8.0.4. x64. This is the Personal Learning Edition, that is freely available for 60 days.
I am trying to get familiar with it.
I tried to replicate some examples available online, such as these two:
first video
second video
and I was successful.
Now I would like to include in my simulations not only a scalar, but an array or a vector of numbers. This is because I would like to use a set of real world data I have for different municipalities and it would be of little informative to do it for each of them separately.
I followed the indications provided here:
Link for the use of the function tabbed array
which substantially provides what I would need. Yet, at the very same page I read "Availability: Professional and DSS only." I am thus inclined to think that this is not a function I can have access to.
I tried to specify an equation for one of my variables by making use of TABBED ARRAY, but I got the error message "Expecting an operator" in the relevant section of the window, as reported below.
I would be very grateful if anyone could help me to understand if the error is related to my sintax, or to the Versim version I am using or to other possible reasons.
I understood, but correct me if I am wrong, that there is a way to work with Vensim by coding but I am not sure this possibility is open to the version I am using.
I do thank you very much for your help.
Marco
I think that error message really comes from the version PLE you are using.
You also could try import the constants from Excel using the GET XLS DATA('file','tab','row or col','cell') function [1]. But this function don't work into PLE version too.
So I advise you use Insight Maker in the first steps of modelling, that is general-purpose simulation and modeling tool, open source and that run in your web browser [2]. On this platform you could import data manually using converters objects [3].
Below we see a print screen from the Insight Maker workspace with a converter object to data import.
Given help from this microsoft link, I am aware of many tools related to SSIS diagnostics:
Event Handlers (in particular, "OnError")
Error Outputs
Operations Reports
SSISDB Views
Logging
Debug Dump Files
I just want to know what is the basic, "go to" approach for (non-production) diagnostics setup with SSIS. I am a developer who WILL have access to the QA and UAT servers where I will be performing diagnostics.
In my first attempt to find the source of an error, I used SSMS to view operational reports. All I saw was this:
I followed the instructions shown above, but all it did was lead me in a circle. The overview allows me to see the details, but the details show the above message and ask me to go back to the overview. In short, there is zero error information beyond telling me which task failed within the SSIS package.
I simply want to get to a point where I can at last see SOMETHING about the error(s).
If the answer is that I first need to configure an OnError event in my package, then my next question is: what would the basic, "go to" designer-flow look like for that OnError event?
FYI, this question is similar to "best way of logging in SSIS"
I also noticed an overall strategy for success with SSIS in this answer. The author says:
Instrument your code - have it make log entries, possibly recording diagnostics such as check totals or counts. Without this, troubleshooting is next to impossible. Also, assertion checking is a good way to think of error handling for this (does row count in a equal row count in b, is A:B relationship really 1:1).
Sounds good! But I'd like to have a more concrete example...particularly for feeding me the basics of what specific errors were generated.
I'm trying to avoid learning ALL the SSIS diagnostic approaches, just for the purpose of picking one good "all around" approach.
Update
Per Nick.McDermaid suggestion, in the SSISDB DB I run this:
SELECT * FROM [SSISDB].[catalog].[executions] ORDER BY start_time DESC
This shows to me the packages that I manually executed. The timestamps correctly reflect when I ran them. If anything is unusual(?) it is that the reference_id, reference_type and environment_name columns are null. All the other columns have values.
Update #2
I discovered half the answer I'm looking for. The reason no error information is available, is because by default the SSIS package execution logging level is "none". I had to change the logging level.
Nick.McDermaid gave me the rest of the answering by explaining that I don't need to dive into OnError tooling or SSIS logging provider tooling.
I'm not sure what the issue with your reports are but in answer to the question "Which SSIS diagnostics should I learn", I suggest the vanilla ones out of the box.
In other words use built in SSIS logging (which does not require any additional code) to log failures. Then use the built in reports (once you get them working) to check those logs.
vanilla functionality requires no maintenance. Custom functionality (i.e. filling your packages up with OnError events) requires a lot more maintenance.
You may find situations where you need to learn some of the SSISDB tricks to troubleshoot but in the first instance, try to get everything you can out of the vanilla reports.
If you need to maintain an SQL 2012 or after existing system, then all of this logging is built in. Manual OnError additions are not guaranteed to be built in
The only other thing to be aware of is that script tasks never yield informative errors. I actually suggest you avoid the use of script tasks in SSIS. I feel that if you have to use a script task, you might be using the wrong tool
Adding to the excellent answer of #Nick.McDermaid.
I use SSIS Catalog error reporting. In most cases, it is sufficient and have the following functionality for error analysis. Emphasis is on the following:
Usually the first or second error message contains meaningful information on error. The latter is some error occurred in the dataflow....
If you look at the first/second error message at All Messages report at Error Messages section, you will see Error Context hyperlink. Invoking it will show you environment, connection managers and some variables at the moment of package crash.
Good error analysis is more an approach and practice than a mere tool selection. Here are my recommendations:
SSIS likes to report error code instead of meaningful explanation. So, Integration Services Error and Message Reference is your friend.
SSIS includes in error context (see above) dump those variables which have Include in ErrorDump property set to true.
I build SQL commands for SQL Task or DataFlow Source in variables. This allows to display SQL command executed at error in error context, when you set incude in Dump property on these variables.
Structure your variables well. If some variable is used only at some task - declare it on this task. Otherwise a mess of dumped variables will hurt you more than do any good.
this article http://www.novicksoftware.com/tipsandtricks/tips-erorr-handling-in-a-stored-procedure.htm makes this claim about SQL Server development: "errors must be checked after every sql statement of interest". The fairly vague online descriptions of the sql debugger for TSQL neither refute nor support this claim.
So, it it really the case that an "easy to debug" stored procedure is one that has 50% of its code dedicated to detecting errors? Or are there better ways to do it, that could come closer to the sort of ease of finding crashes that we are familiar with in stack trace based debugging in modern programming environments?
Is this an area that calls for creating clever new tools to fill the gaps left by imperfection of the existing programming environment or one that calls for me to get with the program and learn some well known state-of-the-art way of getting this stuff done?
ETA: got it on the try-catch, thanks. In fact, to expand on that, here Recording SQL Server call stack when reporting errors is a discussion of how to emulate stack trace since apparently stack trace is not yet supported by SQL Server. Well, at least that's how it can be emulated in your own codebase written after reviewing the article - a legacy codebase without all this stuff would be harder to deal with.
You can use:
ERROR_LINE()
to get information about the line where problem occurred. To use this, you would have to use "try ... catch" for error handling. This information is available in "catch" block.
Documentation : http://msdn.microsoft.com/en-us/library/ms175976.aspx
Examples : http://blog.sqlauthority.com/2007/04/11/sql-server-2005-explanation-of-trycatch-and-error-handling/
I'm a bit confused here. Microsoft as far as I can tell claims that parametrization is the best way to protect your database from SQL injection attacks. But I find two conflicting sources of information here:
This page says to use the ADO command object. But this page says that the command object isn't safe for scripting. I seem to recall reading somewhere that the command object shouldn't be used in VBScript or JScript because of security vulnerabilities, but I can't seem to find that article.
Am I missing something here, or do those two articles seem to contradict each other?
I could be wrong here, but I think this just means that someone could use the Command object to do bad things. I.e. it's not to be trusted if someone else is scripting it.
See safe for scripting in this article. Every instance that talks about this phrase online, references it as if you are marking an ActiveX control saying "This control does no I/O or only talks back to the server that it came from" but the Command object doesn't do that. It can be used to do a lot of things which could be unsafe.
The "safe" they are talking about and the "safe" to prevent from SQL injection are two different things. The article about using the ADO Command object to parametrize your data is spot on. You should do that.
And, Microsoft further confirms this here:
http://msdn.microsoft.com/en-us/library/ms676585(v=VS.85).aspx
I think "safe for scripting" means "safe to be run from a webpage we just retrieved from some Nigerian prince". The command object should be safe to run on the server.
At work though, back in the day my colleagues didn't trust it so we had an in-house framework that basically did the same thing.