As you select each of the other database objects, you'll notice that the set of display editors varies considerably.
It would be tedious to single out each of the object nodes and describe them here. The display editors and data grids behave the same for each of them.
Triggers, functions, procedures, and packages all have their own separate nodes in the Connections navigator. A single-click on any object in these PL/SQL nodes opens as editable PL/SQL code, as shown here:
In the preceding screenshot, the initial Code editor is the editable PL/SQL code editor. This Code editor is included in the set of display editors for the selected procedure.
Tip
Unlike with other database objects, each new selected PL/SQL object opens a new window. In other words, the windows are automatically pinned for the PL/SQL windows. For more information, see the Chapter 4, Working with PL/SQL.
Very often, you may have the connection details for one schema that has access to objects in another schema. One of the most frequently asked questions on the SQL Developer forum is about viewing objects that the schema does not own.
As discussed, the objects under your connection are objects created or owned by the schema defined in the connection. To view any other objects that your connection (schema) has access to, use the Other Users node. When you expand Other Users, for your current connection, you are executing the equivalent SQL query SELECT * FROM ALL_USERS;. This query returns all of the users in the current database. However, it does not mean that you have access to the objects in each of those schemas.
To review the objects the HR schema has access to, expand the Other Users node for the HR connection. Select and expand the user OE, and then expand the Tables node. You should see the selection of OE tables displayed. Not only does HR have access to these objects, the HR schema can query the data. You can select each table and display the set of editors available. HR is not a privileged user, but is granted the SELECT ANY TABLE system privilege.
The user SCOTT/TIGER is another of the Oracle database shipped schemas. SCOTT was the original sample user and is not a privileged user. If you have access to SCOTT, create a new database connection for SCOTT and repeat the exercise. If you expand the OE or HR tables nodes under SCOTT's Other Users node, the nodes are empty. SCOTT does not have access to these objects.
You can expand and work with objects you have access to in the Other Users node. You can also create synonyms for these objects and then, using Filters, display the objects within each respective object type node in your connection.
Consider the following example: the HR schema has access to query the OE's CUSTOMERS table. HR can query the table, using SELECT * from OE.CUSTOMERS;. Now, create a synonym using CREATE SYNONYM CUSTOMERS FOR OE.CUSTOMERS;. This means the HR schema can write the queries without having to refer to the OE schema.
In SQL Developer, the synonym definition appears in the Synonyms node. The CUSTOMERS object will appear in the Tables node by setting the Include Synonyms option in the Filter dialog.
The Recycle Bin was introduced to Oracle databases in Oracle Database 10g. SQL Developer displays the contents of the Recycle Bin in the Recycle Bin node. For supported databases, the Recycle Bin provides a listing of all objects deleted from the schema. The information displayed about dropped objects includes the date the object was created and dropped and whether the object can be un-dropped (reinstated) or purged. SQL Developer displays the original name of the object in the Connections navigator for ease of use. However, once dropped, the object will have a new name. This allows you to drop objects and create new ones without the dropped object name blocking the action. In SQL Developer, displaying the old name makes it easier to decide what object you are dealing with, unless of course you repeatedly recreate and drop the object.