This content has been marked as final. Show 24 replies
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 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.
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
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.