Oracle PL/SQL Language Pocket Reference- P8

exception: weensy_plus := 'Lots of room for me to type now'; When you create a subtype based on an existing variable or database column, that subtype inherits the length or precision and

exception:

weensy_plus := 'Lots of room for me to type now';

When you create a subtype based on an existing variable or database column, that subtype inherits the length (or precision and scale, in the case of a NUMBER datatype) from the original datatype This constraint takes effect when you declare variables based on the subtype, but only as a default You can always override that constraint You will have to wait for a future version of PL/SQL, however,

to actually enforce the constraint in a programmer-defined subtype

Finally, an anchored subtype does not carry over the NOT NULL constraint to the variables it

defines Nor does it transfer a default value that was included in the original declaration of a variable

or column specification

Previous: 4.5 Anchored

Declarations

Oracle PL/SQL Programming, 2nd Edition

Next: 4.7 Tips for Creating and Using Variables

4.5 Anchored Declarations Book Index 4.7 Tips for Creating and

Previous: 4.4 Variable

Declarations

Chapter 4Variables and Program Data

Next: 4.6 Defined Subtypes

Programmer-4.5 Anchored Declarations

This section describes the use of the %TYPE declaration attribute to anchor the datatype of one variable to another data structure, such as a PL/SQL variable or a column in a table When you anchor a datatype, you tell PL/SQL to set the datatype of one variable from the datatype of another element

The syntax for an anchored datatype is:

<variable name> <type attribute>%TYPE [optional default

value assignment];

where <variable name> is the name of the variable you are declaring and <type attribute> is any of the following:

● Previously declared PL/SQL variable name

● Table column in format "table.column"

Figure 4.2 shows how the datatype is drawn both from a database table and PL/SQL variable

Figure 4.2: Anchored declarations with %TYPE

Here are some examples of %TYPE used in declarations:

● Anchor the datatype of monthly_sales to the datatype of total_sales:

total_sales NUMBER (20,2);

monthly_sales total_sales%TYPE;

● Anchor the datatype of the company ID variable to the database column:

company_id# company.company_id%TYPE;

Anchored declarations provide an excellent illustration of the fact that PL/SQL is not just a

procedural-style programming language but was designed specifically as an extension to the Oracle SQL language A very thorough effort was made by Oracle Corporation to tightly integrate the

programming constructs of PL/SQL to the underlying database (accessed through SQL)

NOTE: PL/SQL also offers the %ROWTYPE declaration attribute, which allows you

to create anchored datatypes for PL/SQL record structures %ROWTYPE is described

in Chapter 9

4.5.1 Benefits of Anchored Declarations

All the declarations you have so far seen character, numeric, date, Boolean specify explicitly the type of data for that variable In each of these cases, the declaration contains a direct reference to a datatype and, in most cases, a constraint on that datatype You can think of this as a kind of

hardcoding in your program While this approach to declarations is certainly valid, it can cause

problems in the following situations:

● Synchronization with database columns The PL/SQL variable "represents" database

information in the program If I declare explicitly and then change the structure of the

underlying table, my program may not work properly

● Normalization of local variables The PL/SQL variable stores calculated values used

throughout the application What are the consequences of repeating (hardcoding) the same datatype and constraint for each declaration in all of my programs?

Let's take a look at each of these scenarios in more detail

4.5.1.1 Synchronization with database columns

Databases hold information that needs to be stored and manipulated Both SQL and PL/SQL perform these manipulations Your PL/SQL programs often read data from a database into local program variables, and then write information from those variables back into the database

Suppose I have a company table with a column called NAME and a datatype of VARCHAR2(60) I

can therefore create a local variable to hold this data as follows:

DECLARE

cname VARCHAR2(60);

and then use this variable to represent this database information in my program Now, consider an application which uses the company entity There may be a dozen different screens, procedures, and reports which contain this same PL/SQL declaration, VARCHAR2(60), over and over again And everything works just fine until the business requirements change or the DBA has a change of heart With a very small effort, the definition of the name column in the company table changes to

VARCHAR2(100), in order to accommodate longer company names Suddenly the database can store names which will raise VALUE_ERROR exceptions when FETCHed into the company_name variable

My programs have become incompatible with the underlying data structures All declarations of cname (and all the variations programmers employed for this data throughout the system) must be modified Otherwise, my application is simply a ticking time bomb, just waiting to fail My variable, which is a local representation of database information, is no longer synchronized with that database column

4.5.1.2 Normalization of local variables

Another drawback to explicit declarations arises when working with PL/SQL variables which store and manipulate calculated values not found in the database Suppose my programmers built an

application to manage my company's finances I am very bottom-line oriented, so many different programs make use of a total_revenue variable, declared as follows:

total_revenue NUMBER (10,2);

Yes, I like to track my total revenue down to the last penny Now, in 1992, when specifications for the application were first written, the maximum total revenue I ever thought I could possibly obtain from any single customer was $99 million, so we used the NUMBER (10,2) declaration, which

seemed like plenty Then in 1995, my proposal to convert B-2 bombers to emergency transport

systems to deliver Midwestern wheat to famine regions was accepted: a $2 billion contract! I was just about ready to pop the corks on the champagne when my lead programmer told me the bad news: I wouldn't be able to generate reports on this newest project and customer: those darn total_revenue variables were too small!

What a bummer I had to fire the guy

Just kidding Instead, we quickly searched out any and all instances of the revenue variables so that

we could change the declarations This was a time-consuming job because we had spread equivalent declarations throughout the entire application I had, in effect, denormalized my local data structures, with the usual consequences on maintenance If only I had a way to define each of local total revenue variables in relation to a single datatype

If only they had used %TYPE!

4.5.2 Anchoring at Compile Time

The %TYPE declaration attribute anchors the datatype of one variable to that of another data

structure at the time a PL/SQL block is compiled If a change is made to the "source" datatype, then any program which contains a declaration anchored to this datatype must be recompiled before it will

be able to use this new state of the datatype

The consequences of this rule differ for PL/SQL modules stored in the database and those defined in client-side tools, such as Oracle Forms

Consider the following declaration of company_name in the procedure display_company:

PROCEDURE display_company (company_id_in IN INTEGER)

When PL/SQL compiles this module, it looks up the structure of the company table in the data

dictionary, finds the column NAME, and obtains its datatype It then uses this data dictionary-based datatype to define the new variable

What, then, is the impact on the compiled display_company procedure if the datatype for the name column of the company table changes? There are two possibilities:

● If display_company is a stored procedure, then the compiled code will be marked as "invalid." The next time a program tries to run display_company, it will be recompiled automatically before it is used

● If display_company is a client-side procedure, then the Oracle Server cannot mark the

program as invalid The compiled client source code remains compiled using the old datatype The next time you execute this module, it could cause a VALUE_ERROR exception to be raised

Whether stored or in client-side code, you should make sure that all affected modules are recompiled after data structure changes

4.5.3 Nesting Usages of the %TYPE Attribute

You can nest usages of %TYPE in your declarations as well:

4.5.4 Anchoring to Variables in Other PL/SQL Blocks

The declaration of the source variable for your %TYPE declarations does not need to be in the same declaration section as the variables which use it That variable must simply be visible in that section The variable could be a global PL/SQL variable (defined in a package) or be defined in an PL/SQL block which contains the current block, as in the following example:

4.5.5 Anchoring to NOT NULL Datatypes

When you declare a variable, you can also specify the need for the variable to be NOT NULL This NOT NULL declaration constraint is transferred to variables declared with the %TYPE attribute If I include a NOT NULL in my declaration of a source variable (one that is referenced afterwards in a %TYPE declaration), I must also make sure to specify a default value for the variables which make use

of that source variable Suppose I declare max_available_date NOT NULL in the following example:

max_available_date DATE NOT NULL :=

LAST_DAY (ADD_MONTHS (SYSDATE, 3));

last_ship_date max_available_date%TYPE;

The declaration of last_ship_date will then fail to compile, with the following message:

a variable declared NOT NULL must have an initialization

Next: 4.6 Defined Subtypes

Programmer-4.4 Variable Declarations Book Index 4.6 Programmer-Defined

Previous: 4.3 NULLs in PL/

SQL

Chapter 4Variables and Program Data

Next: 4.5 Anchored Declarations

4.4 Variable Declarations

Before you can make a reference to a variable, you must declare it (The only exception to this rule is for the index variables of FOR loops.) All declarations must be made in the declaration section of your anonymous block, procedure, function, or package (see Chapter 15, Procedures and Functions, for more details on the structure of the declaration section)

When you declare a variable, PL/SQL allocates memory for the variable's value and names the

storage location so that the value can be retrieved and changed The declaration also specifies the datatype of the variable; this datatype is then used to validate values assigned to the variable

The basic syntax for a declaration is:

<variable_name> <datatype> [optional default assignment];

where <variable_name> is the name of the variable to be declared and <datatype> is the datatype or subtype which determines the type of data which can be assigned to the variable The [optional

default assignment] clause allows you to initialize the variable with a value, a topic covered in the next section

4.4.1 Constrained Declarations

The datatype in a declaration can either be constrained or unconstrained A datatype is constrained when you specify a number which constrains or restricts the magnitude of the value which can be assigned to that variable A datatype is unconstrained when there are no such restrictions

Consider the datatype NUMBER It supports up to 38 digits of precision and uses up the memory needed for all those digits If your variable does not require this much memory, you could declare a number with a constraint, such as the following:

itty_bitty_# NUMBER(1);

large_but_constrained_# NUMBER(20,5);

Constrained variables require less memory than unconstrained number declarations like this:

no_limits_here NUMBER;

4.4.2 Declaration Examples

Here are some examples of variable declarations:

● Declaration of date variable:

● This constant date is unlikely to change:

next_tax_filing_date CONSTANT DATE := '15-APR-96';

4.4.3 Default Values

You can assign default values to a variable when it is declared When declaring a constant, you must include a default value in order for the declaration to compile successfully The default value is assigned to the variable with one of the following two formats:

<variable_name> <datatype> := <default_value>;

<variable_name> <datatype> DEFAULT <default_value>;

The <default_value> can be a literal, previously declared variable, or expression, as the following examples demonstrate:

● Set variable to 3:

term_limit NUMBER DEFAULT 3;

● Default value taken from Oracle Forms bind variable:

call_topic VARCHAR2 (100) DEFAULT :call.description;

● Default value is the result of a function call:

national_debt FLOAT DEFAULT POWER (10,10);

● Default value is the result of the expression:

order_overdue CONSTANT BOOLEAN :=

ship_date > ADD_MONTHS (order_date, 3) OR priority_level (company_id) = 'HIGH';

I like to use the assignment operator (:=) to set default values for constants, and the DEFAULT syntax for variables In the case of the constant, the assigned value is not really a default, but an initial (and unchanging) value, so the DEFAULT syntax feels misleading to me

4.4.4 NOT NULL Clause

If you do assign a default value, you can also specify that the variable must be NOT NULL For example, the following declaration initializes the company_name variable to PCS R US and makes sure that the name can never be set to NULL:

company_name VARCHAR2(60) NOT NULL DEFAULT 'PCS R US';

If your code includes a line like this:

company_name := NULL;

then PL/SQL will raise the VALUE_ERROR exception You will, in addition, receive a compilation error with this next declaration:

company_name VARCHAR2(60) NOT NULL;

Why? Because your NOT NULL constraint conflicts instantly with the indeterminate or NULL value

of the company_name variable when it is instantiated

Previous: 4.3 NULLs in PL/

SQL

Oracle PL/SQL Programming, 2nd Edition

Next: 4.5 Anchored Declarations

The Oracle Library

Navigation

Copyright (c) 2000 O'Reilly & Associates All rights reserved

Previous: 4.2 Scalar

Datatypes

Chapter 4Variables and Program Data

Next: 4.4 Variable Declarations

4.3 NULLs in PL/SQL

Wouldn't it be nice if everything was knowable, and known? Hmmm Maybe not The question, however, is moot We don't know the answer to many questions We are surrounded by the Big Unknown, and because Oracle Corporation prides itself on providing database technology to reflect the real world, it supports the concept of a null value

When a variable, column, or constant has a value of NULL, its value is unknown indeterminate

"Unknown" is very different from a blank or a zero or the Boolean value FALSE "Unknown" means that the variable has no value at all and so cannot be compared directly with other variables The following three rules hold for null values:

● A null is never equal to anything else None of the following IF statements can ever evaluate

IF NULL = NULL THEN Even this will never be true

● A null is never not equal to anything else Remember: with null values, you just never know

None of the following IF statements can ever evaluate to TRUE

my_string := 'Having Fun';

IF NULL != NULL THEN This will never be true

● When you apply a function to a null value, you generally receive a null value as a result (there

are some exceptions, listed below) A null value cannot be found in a string with the INSTR function A null string has a null length, not a zero length A null raised to the 10th power is still null

4.3.1 NULL Values in Comparisons

In general, whenever you perform a comparison involving one or more null values, the result of that comparison is also a null value which is different from TRUE or FALSE so the comparison cannot help but fail

Whenever PL/SQL executes a program, it initializes all locally declared variables to null (you can override this value with your own default value) Always make sure that your variable has been

assigned a value before you use it in an operation

You can also use special syntax provided by Oracle to check dependably for null values, and even assign a null value to a variable PL/SQL provides a special reserved word, NULL, to represent a null value in PL/SQL So if you want to actually set a variable to the null value, you simply perform the following assignment:

my_string := NULL;

If you want to incorporate the possibility of null values in comparison operations, you must perform special case checking with the IS NULL and IS NOT NULL operators The syntax for these two operators is as follows:

<identifier> IS NULL

<identifier> IS NOT NULL

where <identifier> is the name of a variable, a constant, or a database column The IS NULL operator returns TRUE when the value of the identifier is the null value; otherwise, it returns FALSE The IS NOT NULL operator returns TRUE when the value of the identifier is not a null value; otherwise, it returns FALSE

4.3.2 Checking for NULL Values

Here are some examples describing how to use operators to check for null values in your program:

● In the following example, the validation rule for the hire_date is that it cannot be later than the current date and it must be entered If the user does not enter a hire_date, then the comparison

to SYSDATE will fail because a null is never greater than or equal to (>=) anything The second part of the OR operator, however, explicitly checks for a null hire_date If either

condition is TRUE, then we have a problem

IF hire_date >= SYSDATE OR hire_date IS NULLTHEN

DBMS_OUTPUT.PUT_LINE (' Date required and cannot

be in future.');

END IF;

● In the following example, a bonus generator rewards the hard-working support people (not the salespeople) If the employee's commission is over the target compensation plan target, then send a thank you note If the commission is under target, tell them to work harder, darn it! But

if the person has no commission at all (that is, if the commission IS NULL), give them a bonus recognizing that everything they do aids in the sales effort (You can probably figure out what my job at Oracle Corporation was.) If the commission is a null value, then neither of the first two expressions will evaluate to TRUE:

IF :employee.commission >= comp_plan.target_commissionTHEN

just_send_THANK_YOU_note (:employee_id);

ELSIF :employee.commission < comp_plan

target_commissionTHEN

While it is generally true that functions which take a NULL argument return the null value, there are several exceptions:

● Concatenation There are two ways to concatenate strings: the CONCAT function (described

in Chapter 11) and the concatenation operator (double vertical bars: ||) In both cases,

concatenation ignores null values, and simply concatenates "around" the null Consider the following examples:

CONCAT ('junk', NULL) ==> junk'junk' || NULL || ' ' || NULL || 'mail' ==> junk mail

Of course, if all the individual strings in a concatenation are NULL, then the result is also NULL

● The NVL function The NVL function (described in Chapter 13) exists specifically to translate

a null value to a non-null value It takes two arguments If the first argument is NULL, then the second argument is returned In the following example, I return the string `Not Applicable'

if the incoming string is NULL:

new_description := NVL (old_description, 'Not Applicable');

● The REPLACE function The REPLACE function (described in Chapter 11) returns a string in which all occurrences of a specified match string are replaced with a replacement string If the match_string is NULL, then REPLACE does not try to match and replace any characters in the original string If the replace_string is NULL, then REPLACE removes from the original string any characters found in match_string

Although there are some exceptions to the rules for null values, nulls must generally be handled

differently from other data If your data has NULLS, whether from the database or in local variables, you will need to add code to either convert your null values to known values, or use the IS NULL and

IS NOT NULL operators for special case null value handling

Previous: 4.2 Scalar

Datatypes

Oracle PL/SQL Programming, 2nd Edition

Next: 4.4 Variable Declarations

The Oracle Library

Navigation

Copyright (c) 2000 O'Reilly & Associates All rights reserved

Previous: 4.1 Identifiers Chapter 4

Variables and Program Data

be placed in that variable

PL/SQL offers a comprehensive set of predefined scalar and composite datatypes A scalar datatype

is an atomic; it is not made up of other variable components A composite datatype has internal

structure or components The two composite types currently supported by PL/SQL are the record and table (described in Chapter 9, Records in PL/SQL, and Chapter 10, PL/SQL Tables, respectively)

The scalar datatypes fall into one of four categories or families: number, character, Boolean, and time, as shown in Table 4.1

date-Table 4.1: Datatype Categories

PL/SQL, just like the Oracle RDBMS, offers a variety of numeric datatypes to suit different

purposes There are generally two types of numeric data: whole number and decimal (in which digits

to the right of the decimal point are allowed)

4.2.1.1 Binary integer datatypes

The whole number, or integer, datatypes are:

The BINARY_INTEGER datatype allows you to store signed integers The range of magnitude of a BINARY_INTEGER is -231 + 1 through 231 - 1 (231 is equal to 2147483647) BINARY_INTEGERs are represented in the PL/SQL compiler as signed binary numbers They do not, as a result, need to

be converted before PL/SQL performs numeric calculations Variables of type NUMBER (see

Section 4.2.1.2, "Decimal numeric datatypes"") do, however, need to be converted So if you will be performing intensive calculations with integer values, you might see a performance improvement by declaring your variables as BINARY_INTEGER In most situations, to be honest, the slight savings offered by BINARY_INTEGER will not be noticeable

NATURAL and POSITIVE are both subtypes of BINARY_INTEGER A subtype uses the storage format and restrictions on how the variable of this type can be used, but it allows only a subset of the valid values allowed by the full datatype In the case of BINARY_INTEGER subtypes, we have the following value subsets:

4.2.1.2 Decimal numeric datatypes

The decimal numeric datatypes are:

Use the NUMBER datatype to store fixed or floating-point numbers of just about any size The

maximum precision of a variable with NUMBER type is 38 digits This means that the range of magnitude of values is 1.0E-129 through 9.999E125; you are unlikely to require numbers outside of this range

When you declare a variable type NUMBER, you can also optionally specify the variable's precision and scale, as follows:

NUMBER (precision, scale)

The precision of a NUMBER is the total number of digits The scale dictates the number of digits to the right or left of the decimal point at which rounding occurs Both the precision and scale values must be literal values (and integers at that); you cannot use variables or constants in the declaration Legal values for the scale range from -84 to 127 Rounding works as follows:

● If the scale is positive, then the scale determines the point at which rounding occurs to the right of the decimal point

● If the scale is negative, then the scale determines the point at which rounding occurs to the left

of the decimal point

● If the scale is zero, then rounding occurs to the nearest whole number

● If the scale is not specified, then no rounding occurs

The following examples demonstrate the different ways you can declare variables of type NUMBER:

● The bean_counter variable can hold values with up to ten digits of precision, three of which are to the right of the decimal point If you assign 12345.6784 to bean_counter, it is rounded

to 12345.678 If you assign 1234567891.23 to the variable, the operation will return an error because there are more digits than allowed for in the precision

1,567,899 to rounded_million, it will be rounded to two million (2,000,000)

rounded_million NUMBER (10,-6);

● In the following unusual but perfectly legitimate declaration, the scale is larger than the

precision In this case, the precision indicates the maximum number of digits allowed all to the right of the decimal point If you assign 003566 to small_value, it will be rounded

to 00357 Because the scale is two greater than the precision, any value assigned to

small_value must have two zeros directly to the right of the decimal point, followed by up to

three nonzero digits

small_value NUMBER (3, 5);

4.2.1.3 The PLS_INTEGER datatype

This datatype is available in PL/SQL Release 2.3 and above

Variables declared as PLS_INTEGER store signed integers The magnitude range for this datatype is

-2147483647 through -2147483647 Oracle recommends that you use PLS_INTEGER for all integer calculations which do not fall outside of its range PLS_INTEGER values require less storage than NUMBER values, and operations on PLS_INTEGER's use machine arithmetic, making them more efficient

Variables declared as pls_integer and binary_integer have the same range, but they are treated

differently When a calculation involving pls_integer overflows, pl/sql raises an exception However, similar overflow involving binary_integers will not raise an exception if the result is being assigned

to a number variable

4.2.2

Numeric Subtypes

The remainder of the datatypes in the numeric category are all subtypes of NUMBER They are

provided in ORACLE's SQL and in PL/SQL in order to offer compatibility with ANSI SQL, SQL/

DS, and DB2 datatypes They have the same range of legal values as their base type, as displayed in

Table 4.2 The NUMERIC, DECIMAL, and DEC datatypes can declare only fixed-point numbers FLOAT, DOUBLE PRECISION, and REAL allow floating decimal points with binary precisions that range from 63 to 126

Table 4.2: Predefined Numeric Subtypes

Subtype Compatibility Corresponding Oracle Datatype

DEC (prec, scale) ANSI NUMBER (prec, scale)

DECIMAL (prec, scale) IBM NUMBER (prec, scale)

FLOAT (binary) ANSI, IBM NUMBER

NUMERIC (prec, scale) ANSI NUMBER (prec, scale)

Prec, scale, and binary have the following meanings:

variable There are, however, several different kinds of character datatypes, each of which serves a particular purpose

4.2.3.1 The CHAR datatype

The CHAR datatype specifies that the character string has a fixed length When you declare a length string, you also specify a maximum length for the string, which can range from 1 to 32767 bytes (this is much higher than that for the CHAR datatype in the Oracle RDBMS, which is only 255) If you do not specify a length for the string, then PL/SQL declares a string of one byte Note that this is the opposite of the situation with the NUMBER datatype For example, a declaration of:

fixed-fit_almost_anything NUMBER;

results in a numeric variable with up to 38 digits of precision You could easily get into a bad habit of declaring all your whole number variables simply as NUMBER, even if the range of legal values is much smaller than the default However, if you try a similar tactic with CHAR, you may be in for a nasty surprise If you declare a variable as follows:

line_of_text CHAR;

then as soon as you assign a string of more than one character to line_of_text, PL/SQL will raise the generic VALUE_ERROR exception It will not tell you where it encountered this problem So if you

do get this error, check your variable declarations for a lazy use of CHAR

Just to be sure, you should always specify a length when you use the CHAR datatype Several

examples follow:

yes_or_no CHAR (1) DEFAULT 'Y';

line_of_text CHAR (80); Always a full 80 characters!

whole_paragraph CHAR (10000); Think of all the spaces

Remember that even though you can declare a CHAR variable with 10,000 characters, you will not

be able to stuff that PL/SQL variable's value into a database column of type CHAR It will take up to

255 characters So if you want to insert a CHAR value into the database and its declared length is greater than 255, you will have to use the SUBSTR function (described in Chapter 11, Character

Functions) to trim the value down to size:

INSERT INTO customer_note

(customer_id, full_text /* Declared as CHAR(255) */)

VALUES

(1000, SUBSTR (whole_paragraph, 1, 255));

Because CHAR is fixed-length, PL/SQL will right-pad any value assigned to a CHAR variable with spaces to the maximum length specified in the declaration Prior to Oracle7, the CHAR datatype was variable-length; Oracle did not, in fact, support a fixed-length character string datatype and prided itself on that fact To improve compatibility with IBM relational databases and to comply with ANSI standards, Oracle7 reintroduced CHAR as a fixed-length datatype and offered VARCHAR2 as the variable-length datatype When a Version 6 RDBMS is upgraded to Oracle7, all CHAR columns are automatically converted to VARCHAR2 (VARCHAR2 is discussed in the next section.)

You will rarely need or want to use the CHAR datatype in Oracle-based applications In fact, I

recommend that you never use CHAR unless there is a specific requirement for fixed-length strings

or unless you are working with data sources like DB2 Character data in DB2 is almost always stored

in fixed-length format due to performance problems associated with variable-length storage So, if you build applications that are based on DB2, you may have to take fixed-length data into account in

your SQL statements and in your procedural code You may, for example, need to use RTRIM to remove trailing spaces from (or RPAD to pad spaces onto) many of your variables in order to allow string comparisons to function properly (These character functions are described in Chapter 11.)

4.2.3.2 The VARCHAR2 and VARCHAR datatypes

VARCHAR2 variables store variable-length character strings When you declare a variable-length string, you must also specify a maximum length for the string, which can range from 1 to 32767 bytes The general format for a VARCHAR2 declaration is:

<variable_name> VARCHAR2 (<max_length>);

as in:

DECLARE

small_string VARCHAR2(4);

line_of_text VARCHAR2(2000);

NOTE: In Version 1.1 of PL/SQL, which you use in Oracle Developer/2000 tools like

Oracle Forms, the compiler does not insist that you include a maximum length for a

VARCHAR2 declaration As a result, you could mistakenly leave off the length in the

declaration and end up with a variable with a maximum length of a single character As

discussed in the section on the fixed-length CHAR datatype, this can cause PL/SQL to

raise runtime VALUE_ERROR exceptions Always include a maximum length in your

character variable declarations

The maximum length allowed for PL/SQL VARCHAR2 variables is a much higher maximum than that for the VARCHAR2 datatype in the Oracle RDBMS, which is only 2000 As a result, if you plan

to store a PL/SQL VARCHAR2 value into a VARCHAR2 database column, you must remember that only the first 2000 can be inserted Neither PL/SQL nor SQL automatically resolves this

inconsistency, though You will need to make sure you don't try to pass more than the maximum

2000 (actually, the maximum length specified for the column) through the use of the SUBSTR

function

Because the length of a LONG column is two gigabytes, on the other hand, you can insert PL/SQL VARCHAR2 values into a LONG column without any worry of overflow (LONG is discussed in the next section.)

The VARCHAR datatype is actually a subtype of VARCHAR2, with the same range of values found

in VARCHAR2 VARCHAR, in other words, is currently synonymous with VARCHAR2 Use of VARCHAR offers compatibility with ANSI and IBM relational databases There is a strong

possibility, however, that VARCHAR's meaning might change in a new version of the ANSI SQL standards Oracle recommends that you avoid using VARCHAR if at all possible, and instead stick with VARCHAR2 to declare variable-length PL/SQL variables (and table columns as well)

If you make use of both fixed-length (CHAR) and variable-length (VARCHAR2) strings in your PL/SQL code, you should be aware of the following interactions between these two datatypes:

● Database-to-variable conversion When you SELECT or FETCH data from a CHAR database column into a VARCHAR2 variable, the trailing spaces are retained If you SELECT or

FETCH from a VARCHAR2 database column into a CHAR variable, PL/SQL automatically pads the value with spaces out to the maximum length In other words, the type of the

variable, not the column, determines the variable's resulting value

● Variable-to-database conversion When you INSERT or UPDATE a CHAR variable into a VARCHAR2 database column, the SQL kernel does not trim the trailing blanks before

performing the change When the following PL/SQL is executed, the company_name in the new database record is set to `ACME SHOWERS···' (where · indicates a space) It is, in other words, padded out to 20 characters, even though the default value was a string of only

12 characters:

DECLARE comp_id# NUMBER;

comp_name CHAR(20) := 'ACME SHOWERS';

BEGIN SELECT company_id_seq.NEXTVAL INTO comp_id#

PL/SQL must compare company_name to parent_company_name It performs the comparison

in one of two ways, depending on the types of the two variables:

❍ If a comparison is made between two CHAR variables, then PL/SQL uses a padding comparison With this approach, PL/SQL blank-pads the shorter of the two values out to the length of the longer value It then performs the comparison So with the above example, if company_name is declared CHAR(30) and

blank-parent_company_name is declared CHAR(35), then PL/SQL adds five spaces to the end of the value in company_name and then performs the comparison Note that PL/SQL does not actually change the variable's value It copies the value to another