This content has been marked as final. Show 24 replies
If your files are in the same format as the stored procedures (so no extra SQL), and you have your PL/SQL File Types in the Preferences set up right, you should be able to work off files too...
Hope that helps,
Ok, I am investgating the file types options.
I have not made any changes to the default install.
If I goto Preferences -> File Types, under the file types tab I see that there is
and they are all set to File Type SQL Script
The Default Editor for SQL Script is SQL Worksheet
I notice that there is also a default editor called 'Code' and this is the default editor for PL/SQL
Are you saying if I change .pkb and .pks to the PL/SQL file type then I will get the correct functionality?
Will there be seperate compile and save buttons?
BTW: I have been trying to change the file types and it turns out it isn't possible as they are all disabled and when you create a new custom extension PL/SQL is not in the list.
If your files have those configured extensions, yes.
However, the developer still reckoned compiling should save implicitly :/
I am having the same difficulty.
Under Preferences | File Types, I see that .sql is set as SQL Script and .pkb .pkh .pks .plb .pls (and others) are set as PL/SQL.
unfortunately, all our files are .sql (procedure, package, function, or script)
In addition, I cannot change the file types or the Default Editors in the Preferences window. The only options I seem to have are Content Type (Text / Binary) and "Open with SQL Developer".
Those are only configurable for user defined extensions, don't ask me why.
So only thing you can do is change your extensions or live with it.
My experience matches yours. I am still using 2.1 for this reason. I wish version 3 could still allow this method of developing.
Our organization has used *.sql for all files, body header etc. Right or wrong, this will not change anytime soon.
Has there been a bug or feature request logged for this?
I agree that you should see errors in the log when working with a script file. We are also working in this fashion and it is now a issue since developers do not want to upgrade to a new SQL Developer version as they will not be able to work comfortably with .sql files.
I really think this is an issue which should be looked at?
When I create (or replace) a large package in SQL Developer with many functions/procedures I have the same problem. I added the following line at the bottom:
show err package body <name package body>;
Works fine :)