< previous page page_146 next page > Page 146 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- < previous page page_146 next page > < previous page page_147 next page > Page 147 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 < previous page page_147 next page > < previous page page_148 next page > Page 148 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. < previous page page_148 next page > < previous page page_149 next page > Page 149 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 < previous page page_149 next page > < previous page page_150 next page > Page 150 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 < previous page page_150 next page > < previous page page_151 next page > Page 151 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 */ < previous page page_151 next page > < previous page page_152 next page > Page 152 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> /* < previous page page_152 next page > < previous page page_153 next page > Page 153 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. < previous page page_153 next page > < previous page page_154 next page > Page 154 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. < previous page page_154 next page > < previous page page_155 next page > Page 155 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. < previous page page_155 next page > . 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. & ;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. 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& gt; DEFINE sql_ type = PL/ SQL& gt;