Use the View Editor to view, create, or alter views.
|
About Views |
A view is a query that is named in the database so that it can be used as if it were a table. It can be thought of as a virtual table in the database whose contents are defined by the Select query.
You can use views to rearrange, filter and select the way you see data in tables without creating any copies of that data. Views help make data access simpler by hiding complexities. They can also help separate data for different users as a security measure.
SQL Navigator’s view editor makes it easy to create and alter views. Although you won’t need to type any PL/SQL code when editing views in SQL Navigator, you should be familiar with Oracle rules and guidelines for using views.
The attributes of this database object are described in Oracle documentation. |
Using The Editor
Editor Toolbar
 |
Create new view |
Click to open the New View dialog. |
 |
Open object from DB |
Open an existing view. |
 |
Clone current view |
Create a clone of the selected view. You will be prompted in the New View dialog to enter a new name. |
 |
Revert to pervious view |
Undo or revert any modifications made to the view. |
 |
Generate SQL for changes |
Generate SQL code for the changes made. |
 |
Apply changes to DB |
Apply changes to the database. |
Editor Tabs
|
Text |
|
Create View ( |
Enter the view column names, separated by commas. |
|
) AS |
Type the SQL for the view.
If you enter the Select * syntax to include all the table columns in the view, then all the table column names from the Select * table appear automatically in the CREATE VIEW pane. | |
|
Columns |
- Select a column.
- Right click and select Edit Comments
- Enter any comments required.
- Repeat for each column as appropriate.
|
|
Options |
Select from the available options to be applied to the view. |
|
Comment |
Enter any comments related to the view. |
Ways to Open The View Editor
Features:
- Load a Java source file from the database into the editor
- Create a new Java source file
- Clone an existing Java source
- View and edit Java source with color syntax highlighting
- Compile the Java object
- Save the Java class to the database.
To see tooltips describing the toolbar buttons, simply point to them.
Ways to open the Java Editor
Use the Instance Property Editor to view or specify the startup parameters for the instance.
|
About Instance Properties |
The characteristics of the Oracle database instance are specified during startup. These parameters are stored in a file called init.ora. This file may, in turn, call a corresponding config.ora file.
The Instance Property Editor is based on what the Oracle v$parameter data dictionary view reports. Some attributes are Session Modifiable, which means that they are applied immediately to the current session, but are not permanent. Others are System Modifiable and further may be Immediate or Deferred (requiring a server shutdown/restart). Some are not modifiable at all.
These parameters and the rules governing their usage are described in Oracle reference sources. |
Using The Editor
Instance Property
Select the Instance Property you want to view. Not all properties can be modified.
 |
The Property can be modified. |
 |
The Property cannot be modified. |
Editor Toolbar
| |
Create new Instance property |
N/A to the Instance Property Editor. Oracle does not allow this action. |
| |
Open object from DB |
Open the property from the current database |
| |
Clone current Instance property |
N/A to the Instance Property Editor. Oracle does not allow this action. |
| |
Revert to pervious Instance property |
Undo changes made to the property. |
| |
Generate SQL for changes |
Generate SQL code for the changes made |
| |
Apply changes to DB |
Apply the changes to the database |
Details Tab
| Description |
Brief description of the parameter |
| Is Default |
Whether this parameter has been specified by the user as an initialization parameter |
| System Modifiable |
Whether this parameter can be modified at an instance-wide level dynamically after the instance has started |
| Session Modifiable |
Whether this parameter can be modified at the session level |
| Is Modified |
Whether this parameter has been modified after instance startup, and if so, whether it was modified at the session level or at the instance (system) level |
| Is Adjusted |
Whether Oracle has adjusted a value specified by the user |
| Type |
The Oracle datatype |
| Value |
Current value for this session (if modified within the session); otherwise, the instance-wide value |
| Alter For |
Whether the new value is to be current for this session or instance-wide |
Ways to Open The Instance Property Editor
| |
From the Main Menu
View Menu | Visual Object Editors | Instance Property Editor |
Open the Instance Property Editor. |
 |
From DB Navigator
Right click on a Property object and click Open. |
Open the selected object in the Instance Property Editor. |
Team Coding and Version Control Support
Team Coding controls database objects and source files, such as procedures and functions. Team Coding enables you to organize code work among different projects and control access to the code objects by locking them in the database. You can use Team Coding alone or in conjunction with a version control system (VCS).
Use Team Coding with a VCS
Used with a VCS, Team Coding provides full source control with locking and full revision history. Team Coding interfaces directly with the VCS to provide this control. Team Coding keeps track of changes to objects and prevents modifications to the code in the database unless a SQL Navigator user checks the source out of the VCS through Team Coding. Team Coding with a VCS works as follows:
- When the SQL Navigator user issues a check-out command, SQL Navigator checks a revision out of the VCS and saves the code to the local SQL Navigator environment.
- When the SQL Navigator user saves the code, SQL Navigator writes it to the database.
- When the SQL Navigator user issues a check-in command, SQL Navigator checks the revision into the VCS.
The Team Coding Administrator creates one or more Team Projects and associates them with projects in the VCS. For more information, see Setup Team Projects.
Use Team Coding without a VCS
Used without a VCS, Team Coding works as follows:
- Administrators must protect production schemas by creating one or more Team Projects, which are the only way that developers can check objects in and out of the database and work on them. This allows the developers to work on the objects in their local environments without affecting the original objects.
- When a developer checks out an object through a Team Coding Project, SQL Navigator locks the object in the database. This prevents the developer from unintentionally overwriting changes made to that object by other developers. The developer checks the finished code into the database through the Team Project, which unlocks the object again. For more information, see Check in and Check out.
- Team Coding without a VCS does not provide revision history as a VCS would. The source code is maintained in the database, with no other versions available (other than through your own normal backup methods). SQL Navigator does provide one "undo" option, which is to undo the check-in. For more information, see Team Coding Manager.
Work with non-controlled objects
When Team Coding is installed with a VCS, you also have full edit access to objects in the VCS that are not controlled in Team Coding. This access is controlled from the Team Coding Manager. You can check those objects into and out of the VCS to work on them in the Code Editor. The Team Coding Manager shows you which objects are under the control of Team Coding (and therefore must be accessed through a Team Project) and which can be accessed directly from the VCS.
Install Team Coding
Administer Team Coding
Objects Supported by Team Coding
Version Control Systems
