2 Replies Latest reply on Apr 6, 2016 1:18 PM by thatJeffSmith-Oracle

    Working with views is awkward (SQL Developer 4.x)


      I've been working a lot with views lately and the flow when doing things with views is a lot more awkward than other common database objects.


      When you edit a procedure, package, function - it opens in it's own tab that has some extra controls for compiling, etc.  And, at it's heart, a view is just a chunk of SQL.  Well, most things are just SQL, but literally a view is just a glorified Select statement.

      When  you edit a view, though, it opens a modal window so you can't click a anything in the object explorer to find table or column names, etc.  You can't even switch to a different tab if, say, somebody calls with some minor task on another database like nine times a day.  You've got to close the view dialog.  And you can't close the view dialog if the changes to the view won't compile (yes, you can FORCE, but that's on another tab).  It's actually easier for me to copy the SQL, cancel the view edit dialog, and paste the SQL into a temporary window to work on view edits.  So, the view edit window is used only for very simple edits.


      Ideally, if editing a view, it would open in it's own separate tab (like editing a PL/SQL procedure or function does) that would allow normal interaction with the rest of the tool (other tabs, object explorer, etc).


      Having a way to "test" the view not only for syntax, but view data returned would be nice.


      I'll leave it to the experts to work out the details on all that.  I'd be happy to give constructive feedback on any progress, too! 


      For your consideration,