This content has been marked as final. Show 24 replies
You will only get output in the compiler log window if you click on the compile button in a pl/sql editor. Running an anonymous block in the worksheet isn't really 'compiling' (I know it gets compiled, but only as preparation for running it.)
I don't think previous versions were any different.
I was working with the previous version this morning and it did show the compiler window with a summary of the errors.
I then upgraded to the latest functino and lost this behavour :(
I have a faint memory of changing an option or something to make this happen but I can't reacll. I also can't find any options to do it.
I've just run up 2.1 and it behaves as I described.1 person found this helpful
I have tested on my coluges PC with the same result as you.
I have rescued my 2.1 install from my recycle bin and tried the example I gave and it didn't work, so I have made a mistake with the example
I then tried the following:
CREATE OR REPLACE PACKAGE icar_int_pkg
In my 2.1 version I do get the compiler - log with the error.
My coluge has 2.1 and he gets the compier - log
with my 3.0 version I do not get the compiler - log.
Does anyone have any solution to this?
You can always try deleting the whole SQL Developer folder under the (hidden) Application Data of your Windows user profile. This will reset all to default.
Hope that helps,
I can reproduce this. I'll follow up on this and get back to you.1 person found this helpful
Did you have any luck with the follow up?
Hi I am also having the same problem , can you please help me regarding this .. in detail
If Sue has had the time to follow up, it apparently did not manifest as a new bug. I did not check for any old bugs.
Anyway, the change in behavior was probably intentional to improve internal consistency in the tool. For errors in anonymous blocks in a worksheet, neither 2.1 nor 3.0 brings up the compiler log. Any error message displays only in the script or statement output tabs.
As for package, function, and procedure definitions, the first attempt to execute the DDL in a worksheet results in a new node of the appropriate name and type appearing in the Connections tree view (whether the compile succeeds or fails). This may require a "Refresh" for the object to display in the tree. If there is some issue during compilation, the 2.1 output tab shows, for example,
PROCEDURE XYZ compiled
Errors: check compiler log <--- implying an intent to display details in the compiler log
whereas the 3.0 output tab shows
PROCEDURE xyz compiled
Warning: execution completed with warning <--- implying no intent to display details in the compiler log
Subsequent create invocations (without the "or replace" syntax) results in a "ORA-00955: name is already used by an existing object" error, hinting that opening the PL/SQL editor on the object from the Connections tree view is really the appropriate action to take.
Notice also, in the 2.1 compiler log, that right clicking on the error and selecting "Go to Source" does nothing for PL/SQL code executed from the worksheet. It only goes to the proper source line for code compiled from the PL/SQL editor.
The tool, by pushing you toward use of the PL/SQL editor, is probably doing you a favor. The PL/SQL environment is a superior development environment as compared to the worksheet trying to emulate SQL*Plus. For example, some SQL*Plus features (such as variable declarations for use as bind variables) are not fully implemented in SQL Developer. The implementation of the PL/SQL context seems much more solid.
SQL Developer Team
Hi , thanks for your reply ..
but is there any alternative to see errors .. (other than show errors).
As Gary suggested, use the PL/SQL editor, by opening/compiling from the procedure under the navigator node.
I can see what you are saying. I noticed the problem that you were not able to jump to errors in the compiler log by double clicking on them (Unless you are in PLSQL editor).
This change has really messed up our workflow. We work developing code across many enviroments (Dev, Dev2, Dev3, Test, Prod and more) as a result we do not work mainly from objects in the database. Instead we have text files which compile all the objects. We use an ancient source control system and my company has been working like this for many (many) years.
The fact that pressing the 'save' button in PLSQL editor compiles the procedure/package/whatever is really conuterintiative. I want the save button to save a text file! The way I work is load the text file into SQL Developer, press the 'run script' button to compile, and the save button works as intended to save the text file!
I used to be able to see errors appearing all be it not double click to find them. Now I have to use the show errors statment just to see the errors, and even worse when I have a package script that first creates a package header, then creates a body and there is an error in the header I need to delete the body, run just the header and show errors on that.
I can see how the whole design of SQL developer is based around editing database objects not scripts that create database objects but this dosn't work for us. All our database objects come from scripts and it is the scripts that we need to maintain. These scripts become patches which we can apply to each of the enviroments. The way SQL developer is setup we keep having to write the code whatever way we can and then cut and paste it into the relevant script.
This isn't a good way of working at all.