Line numbering in the Command Window

[Tim Scott]

I guess my main issue is that I can't seem to get these to display - or print - in the Command Window's Editor. Am I missing something?

It struck me also that it would be very useful to have two line number sequences showing on this Editor Window: one for the actual line in the file and one that starts again with every

create [or replace] [procedure|function|package [body] ] ...

This way, when the Commands are executed, it's a lot simpler to track back to the source line in the PL/SQL package / procedure to find where the problem is.

Just thought I'd say something rather than grumbling to myself all the time .

 

[Marco Kalter]

I guess my main issue is that I can't seem to get these to display - or print - in the Command Window's Editor. Am I missing something?

The Command Window does indeed not have line numbers.

This way, when the Commands are executed, it's a lot simpler to track back to the source line in the PL/SQL package / procedure to find where the problem is.

That's what the Program Window is for . It will tell you exactly where the error is and allows you to quickly fix and recompile.

 

[Tim Scott]

That's what the Program Window is for . It will tell you exactly where the error is and allows you to quickly fix and recompile.

I know - that's very helpful for investigating / debugging. Our product, however, is built and installed using many many command scripts that get run by sqlplus. These scripts each contain the package bodies or headers for several packages grouped into distinct logical areas of the application. They also contain sometimes invaluable revision history in comments before the first 'create or replace ...' which never gets to the database. Editing a Program in the Program Window works great, but saving that development to the appropriate point in the Command File isn't terribly simple.

Maybe if there was an easy way to navigate to the Program Window for the current package (body) and to easily copy/paste that package source back to the command file ??

eg: a right-click or edit menu options in the Editor to "select entire procedure/package/..." and/or "open database version of this object in a new Program Window" and/or "replace this procedure/package/... with the source from database".

Thoughts welcome ... and don't get me wrong: it's a wonderful product and I'm looking forward to the excellent ideas that will no doubt appear in future releases.

 

[Worker]

These scripts each contain the package bodies or headers for several packages grouped into distinct logical areas of the application.

A program window will open these all in individual tabs. Would it help if there was a way to compile only a single tab in a program window?

(I've wondered about the usefulness of this for myself before. Sometimes you just want to compile the body and not the header, to avoid invalidating other packages.)

 

[Tim Scott]

A program window will open these all in individual tabs. Would it help if there was a way to compile only a single tab in a program window?

Yes, it probably would. I wasn't even thinking as far as opening all program units in the file, just the one at/around the current cursor position - but you make a good point: it should be capable of compiling, eg: just the current window. Maybe there could be an option to compile all / this / ..

 

[Marco van der Linden]

Normally if you press the 'execute' button all tabs will be executed (compiled). There is, however a 'compile current' plug-in which will only execute (compile) the active tab. (Available through http://www.bar-solutions.com/software/plug-ins.html).
I have always liked this plug-in and use it extensively to compile package body only while developing.

 

[Gustavo]

In addition, you could set the "Ignore unrecognized PL/SQL" option under "Program Window" preferences. This will make PLSD ignore your SQL*Plus "set" commands, "prompt"s and so on.

 

[Tim Scott]

Thanks Gustavo - that seems to work very well in my very simple test. I'll try with some more complicated scripts and see how that goes.

I don't get to see the SQL*PLus-like output of the command window that we will also need to review, but it's certainly a lot simpler to pin down the build problems in the code. We could always switch back to a Command Window and run it before completing the task.