After opening a file, selecting connection from the dropbox, and compiling it, the compilation unit resides in the two places: in the filesystem, and the db. We store this file-db association as a binary relation in project.qbql file. Here is an example:
project.qbql is currently used for debugging: a user can start debugging for a compilation unit opened from filesystem, and the debugging process would refer to file based source, not the one stored in the db. In the context of this discussion if a file is associated with only one database object (like ERR_DEMO in the above example), then we know what is the "default" connection, so that a user can be spared from one extra step of setting the connection whenever opening err_demo.pkb.
Edited by: Vadim Tropashko on Jan 9, 2013 11:30 AM
if a file is associated with only one database object (like ERR_DEMO in the above example), then we know what is the "default" connection, so that a user can be spared from one extra step of setting the connection whenever opening err_demo.pkb.So if I open err_demo.pkb and I have ONE connection open which is different from what you consider "default", clicking Compile will open the default connection and compile against it?
Or, if I open a file never compiled before (therefore lacking a "default" connection) and I have ONE connection open, I will be forced to choose a connection?
This is not the "old" behaviour I was talking about and is even worse than the current, IMO.
I either hope I'm misunderstanding something (quite possible) or you will reconsider this approach.
Vadim Tropashko wrote:Thank you for pursuing this Vadim.
I failed to reproduce the problem. Step-by-step test case:
1. Create file scott.mysimplepkg.pks
create or replace PACKAGE scott.mySimplePKG AS
FUNCTION add (par1 number, par2 number)
2. Open file. It is opened in PL/SQL editor (not worksheet). The connection combobox is empty.
3. Select connection. It is immediate if connection is active, and some time to connect, otherwise. (The connection widget is not associated with the editor content by any means).
Can you please elaborate?
After more experimentation I can now see that this is also due to the file extension of the package file. Your example (above) works well for me also. However, if I change the file name to "scott.mysimplepkg.bdy" (bdy is what we use here) and then open in SQL Developer, the file is not treated as code and no connection drop-down is given. Is there a way of adding new file extensions to a list of recognised types.
Preferences -> File Types -> Add...
Add .bdy extension. Associate it with PL/SQL editor.
P.S. This manual association is supposed to be legacy, because we are trying to parse the source and identify it as PL/SQL compilation unit. However, as you have correctly observed, the parser failed on schema.pkg_name; this has been fixed for future release.
Lets summarize what we have:
1. Before 3.2 newly opened file based PL/SQL editor were associated with "default" connection, and as xxsawer noted this was a bug.
2. After 3.2 newly opened editor is not associated with any connection and requires user to explicitly choose one.
After little reflection it seems that correct fix is for a newly opened editor to look into project.qbql mapping, and if there is an entry there, then choose this connection (which, of course, can be changed if user wants so). Am I missing any other usage scenario?
Edit: implemented for EA2.