Oracle SQL Plus The Definitive Guide- P18 doc

Deleting a variable The following example deletes the three variables created earlier when the DEFINE command was discussed: SQL> UNDEFINE fiscal_year SQL> UNDEFINE my_publisher my_edito

these types of constants in a user variable makes the script more maintainable because changes to the values can be made in one central place

The UNDEFINE Command

The UNDEFINE command deletes a variable definition If you have created a variable containing sensitive information, such as a password, you can use UNDEFINE to delete it when it is no longer needed It's also not a bad idea to

UNDEFINE all your variables at the end of a script, so they don't linger and possibly affect the execution of other

scripts that you run

Syntax for the UNDEFINE command

The syntax for UNDEFINE looks like this:

UNDEF[INE] variable_name [ variable_name ]

where:

UNDEF[INE]

Is the command, and may be abbreviated to UNDEF

variable_name

Is the name of a user variable to delete You can delete several variables with one command by listing them out,

separated by spaces

Deleting a variable

The following example deletes the three variables created earlier when the DEFINE command was discussed:

SQL> UNDEFINE fiscal_year

SQL> UNDEFINE my_publisher my_editor

SQL> DEFINE my_publisher

symbol my_publisher is UNDEFINED

SQL> DEFINE my_editor

symbol my_editor is UNDEFINED

SQL> DEFINE fiscal_year

symbol fiscal_year is UNDEFINED

As you can see, after using UNDEFINE to delete the variables, they can no longer be referenced

Controlling Variable Substitution

As you use SQL*Plus, two problems will eventually arise concerning the use of substitution variables The first problem you are likely to encounter is that you will need to use an ampersand somewhere in your script, and you won't mean for

it to be part of a substitution variable name This is a very common problem, and

hap-pens most often when you're using an ampersand in a quoted string or as part of a comment.

The second problem, which you may never encounter at all, is that you may want to place a substitution variable smack

in the middle of a word This is a less common problem, and may not be an issue at all depending on the types of scripts you write

SQL*Plus provides several ways to deal with these problems A special escape character can be used whenever you need to place an ampersand in your script and have it stay there A concatenation character is provided for those

unusual cases where you want to place a substitution variable at the beginning or middle of a word You can change the substitution character entirely if you don't like using the ampersand and want to use some other character instead

Finally, if you aren't really into writing scripts, you can turn the substitution feature completely off Then you won't have to worry about it at all

The Escape Character

The escape character preceding an ampersand tells SQL*Plus to leave it alone that it is not part of a substitution

variable Consider the following DEFINE command:

DEFINE company_name = O'Reilly & Associates

If you tried to execute that command, SQL*Plus would interpret & Associates as a substitution variable, and would prompt you to supply a value The result would look like this:

SQL> DEFINE company_name = O'Reilly & Associates

Enter value for associates:

That's obviously not the behavior you want, yet the ampersand is legitimately part of the name, so what do you do? One solution is to precede the ampersand character with a backslash, which is the default SQL*Plus escape character, like this:

DEFINE company_name = O'Reilly \& Associates

The escape feature is not on by default In order for this to work, you need to enable it first

Turning on the escape feature

By default, SQL*Plus does not check for escape characters when looking for substitution variables This is a feature you must turn on before you use it The command to do that is:

SET ESCAPE ON

Once turned on, this setting remains in effect until you turn it off again, or until you exit SQL*Plus.

Escaping an ampersand

Now that the escape feature has been turned on, you can place a backslash in front of any ampersand characters that you need to embed in your script The following is a modified version of the previous example that correctly assigns the text O'Reilly & Associatesto the company_name variable:

SQL> DEFINE campany_name = O'Reilly \& Associates

SQL> DEFINE company_name

DEFINE COMPAY_NAME = O'Reilly & Associates (CHAR)

Because of the preceding backslash, SQL*Plus leaves the ampersand alone, and the company_name variable is created containing the desired text

One thing to keep in mind when you have the escape feature turned on is that you must escape the escape character itself when you need to use it as part of your script For example, to define a string containing one backslash, you must double the backslash character as shown in the following code:

SQL> DEFINE backslash = \\

SQL> DEFINE backslash

DEFINE BACKSLASH =\ (CHAR)

If you are using the backslash a lot, and this causes you problems or becomes cumbersome, you can change the escape character to something else

Changing the escape character

If you don't like using the backslash as the escape character, you can use the SET ESCAPE command to specify a

different character more to your liking The following command changes the escape character to be a forward slash: SET ESCAPE /

Changing the escape character also turns the escape feature on There is no need to subsequently issue a SET ESCAPE

ON command

Any time you issue the SET ESCAPE ON command, the escape character is reset to the

default backslash This is true even if the escape feature was on to begin with Keep this in

mind whenever you issue SET ESCAPE ON, especially if you are using an escape character

other than the default

The Concatenation Character

There may come a time when you want to use a substitution variable in a situation where the end of the variable name is not clear Consider the following code example:

DEFINE sql_type = PL/

PROMPT &sql_typeSQL

The intent is to have SQL*Plus print the text PL/SQL, but SQL*Plus won't substitute PL/ in place of &sql_type

Instead, it will interpret the entire string of &sql_typeSQL as a variable

You can get around this problem by using the SQL*Plus concatenation character The period is the default

concatenation character, and it explicitly tells SQL*Plus where the variable name ends The following code example shows the concatenation character being used to make the substitution work as intended:

SQL> DEFINE sql_type = PL/

SQL> PROMPT &sql_type.SQL

PL/SQL

Turning off the concatenation feature

By default, the concatenation feature is always on SQL*Plus looks for the period immediately following any

substitution variables encountered in the script If you need to, you can turn this feature off with the following command: SET CONCAT OFF

It's usually not necessary to turn this feature off You would only need to do it if you were using periods after your substitution variables and you didn't want those periods to disappear from your script With concatenation on, any period immediately following a variable is used to mark the end of the variable name, and is removed from the script when the variable substitution is made

Changing the concatenation character

The default concatenation character can cause a problem if you intend to use a substitution variable at the end of a sentence The problem is that the period at the end of the sentence will go away because SQL*Plus sees it as the

concatenation character ending the variable name Here's an example:

SQL> DEFINE last_word = period

SQL> PROMPT This sentence has no &last_word

This sentence has no period

Their are only two ways to deal with this problem One is to turn the concatenation feature off The other is to change it

to something other than a period The following command changes the concatenation character to an exclamation point: SET CONCAT !

Now you can reexecute the example, and the period at the end of the sentence shows up as expected:

SQL> DEFINE last_word = period

SQL> PROMPT This sentence has no &last_word

This sentence has no period

As with the SET ESCAPE command, using SET CONCAT to change the concatenation character also turns the feature on

Any time you issue the SET CONCAT ON command, the concatenation character is reset to

the default period This is true even if the concatenation feature was on to begin with Keep

this in mind whenever you issue SET CONCAT ON, especially if you are using a

concatenation character other than the default

Enabling and Disabling Substitution

You can turn variable substitution completely off with this command:

SET DEFINE OFF

Sometimes it's easier just to turn substitution completely off rather than worry about how you use ampersand and escape characters in your scripts If you have a large block of script that doesn't reference any variables, you can toggle

substitution off just for that block, and turn it on again afterwards For example:

SET DEFINE OFF Toggle substitution off for the next few commands

Script that doesn't reference substitution variables goes here

SET DEFINE ON Toggle substitution back on when needed again

To reenable substitution, simply issue:

SET DEFINE ON

Changing the Substitution Variable Prefix Character.

If you don't like prefixing your substitution variables with an ampersand, or if you need to use ampersands in your script, you can tell SQL*Plus to use a different character for substitution You can pick any character you like, but it should be something that stands out

Changing the substitution variable prefix character

The following command changes the substitution variable prefix character to a caret:

SET DEFINE

Changing the substitution character can be a handy thing to do if you need to use ampersands in a lot of text constants or

if, like me, you tend to use them often in comments The following code illustrates how to change from an ampersand to

a caret and back again:

SQL> DEFINE message = Brighten the corner where you are

SQL> SET DEFINE

SQL> PROMPT &message

&message

SQL> PROMPT message

Brighten the corner where you are

SQL> SET DEFINE &

SQL> PROMPT &message

Brighten the corner where you are

SQL> PROMPT message

Message

Another way to reset the substitution character back to the default ampersand is to issue the SET DEFINE ON

command A side effect of issuing SET DEFINE ON is that the substitution character is always reset to the default This

is true regardless of whether substitution is currently on or off

Commenting Your Scripts

If you write extensive scripts, you should write extensive comments In fact, any time you write a script, no matter how short, consider including a few comments to explain the purpose of the script

Comments may be placed in a script using any of the following three methods:

1 By using the REMARK command

2 By using double-hyphen characters

3 By delimiting the comment by/* and */

Each method works just a bit differently from the others You will probably find yourself gravitating towards the /**/ and - - delimiters The REMARK command is cumbersome, and consequently isn't used very often

The REMARK Command

The REMARK command may be used to place comments in a SQL script Any text on the same line following the REMARK command is considered a comment The REMARK command may also be abbreviated to REM, as the following example shows:

REMARK This is a comment

REM This is a comment too

SQL*Plus does not look for substitution variables in the text following a REMARK command, so you are free to use ampersands, and any other characters you like, in your comments

The /* and */Delimiters

The /* and */ delimiters are familiar to many programmers, and may also be used to delimit comments in SQL*Plus Comments created using this method may span multiple lines, for example:

/*

This is the second line of a comment

This is the third line

*/

You can also use /* and */ to add comments to SQL queries, for example:

SELECT *

FROM employee

WHERE /* employees are current */

SYSDATE BETWEEN employee_hire_date

AND nvl(employee_termination_date,SYSDATE);

An interesting side effect of using /* and */ is that when you use them to mark off complete lines of comments in a script, those lines are echoed to the display For example, if you place the following commands in a file:

/*

This script selects the current date from the

DUAL table, and displays it for you to see

*/

SELECT SYSDATE FROM DUAL;

then execute that file, your output will look like this:

SQL> @c:\jonathan\sql_plus_book\xe_ch_5\comtest

SQL> /*

DOC>This script selects the current date from the

DOC>DUAL table, and displays it for you to see

DOC>*/

SQL> SELECT SYSDATE FROM DUAL;

SYSDATE

-

18-MAR-98

This echoing occurs regardless of whether the echo setting is currently on or off It will only occur when the comment starts on a line by itself Comments that you embed within a SQL query will not be displayed in this manner

Note that comments may not be nested

Double Hyphens (- -)

Double hyphens may be used to delimit comments in much the same manner as the REMARK command Anything following the double hyphen is considered a comment Here are some examples:

Describe the employee table

DESCRIBE employee

Select all currently employed people

SELECT *

FROM employee

WHERE employees are current

SYSDATE BETWEEN employee_hire_date

AND NVL(employee_termination_date, SYSDATE);

As with /**/, the double hyphen may be used to embed comments within SQL queries and PL/SQL blocks The only difference is that double hyphen comments cannot span lines

Substitution Within Comments

SQL*Plus doesn't normally check comments for substitution variables, but the rules change when comments are

embedded in a SQL query or a PL/SQL block Thus, you can enter the following comment, and SQL*Plus won't treat

&VAR as a substitution variable:

SQL> In this comment, &VAR is not a substition variable

However, if you enter a similar comment as part of a SQL query, SQL*Plus will see &VAR as a substitution variable, for example:

SQL> SELECT *

2 FROM employees

3 Now, &VAR is treated as a substitution variable

4 WHERE employee_termination_date IS NULL;

Enter value for var:

The reason for this seemingly inconsistent behavior is that SQL*Plus does not parse your SQL statements; instead, they are sent to Oracle As soon as SQL*Plus sees that you have begun to type in a SQL command, it stops parsing and accepts whatever text you enter into the buffer Before the contents of the buffer are sent to Oracle, SQL*Plus must replace any substitution variables with their contents In doing this, it simply scans the entire buffer, including any comments it contains

Substitution is never an issue with the REMARK command, because REMARK is a SQL*Plus command and can never

be used in a SQL query

5

Extracting and Loading Data

In this chapter:

Types of Output Files

Limitations of SQL*Plus

Extracting the Data

Reloading the Data

SQL*Plus can be used to extract data from Oracle for use in a spreadsheet or some other application The need to do this is so common that it's a wonder Oracle doesn't supply an application specifically for that purpose Unfortunately, they don't Oracle does provide SQL*Loader, a utility that can load data into Oracle from almost any form of flat file, but there is no corresponding SQL*Unloader

Oracle does, however, provide SQL*Plus Even though it's not a generic data extraction utility, through the creative use

of SQL and SQL*Plus's formatting options, you can extract numeric, date, and text data to a flat file Depending on your needs, you can format the file as a comma-delimited file, a tab-delimited file, or you can format the data in fixed-width columns Comma-delimited files are most useful if you are transferring data to a spreadsheet such as Lotus 1-2-3,

or a desktop database such Microsoft Access Fixed-width, columnar data files are often used to transfer data to legacy applications

In addition to simply extracting data, you can get more creative and use SQL*Plus to generate a script file containing SQL statements This is referred to as using SQL to write SQL You can do something as simple as generating a flat file

of INSERT statements to be used in recreating the data at another site, or you can generate a file of Data Definition Language (DDL) statements to modify your own database I've even seen people use SQL*Plus to generate operating-system shell scripts to use in modifying and maintaining their database

In this chapter, I will walk you through the process of writing a script to extract data from the sample database into a flat file You will see how SQL can be written to produce a comma-delimited text file, a fixed-width text file, or a file of INSERT statements Once this is done, you will see how that same data can be loaded back into Oracle