Errata

SET AUTOCOMMIT - the default is OFF (fortunately !) and it doesn't have anything to
do with exiting of SQL*Plus. Instead, it means that pending changes are/aren't
commited after each INSERT, UPDATE, ... statement.
The EXIT command has these options [COMMIT | ROLLBACK], COMMIT is the
default.

Current as in book:
SQL> WHENEVER SQLERROR SQL.SQLCODE EXIT ROLLBACK

Should be:
SQL> WHENEVER SQLERROR EXIT SQL.SQLCODE ROLLBACK

"SQL*Plus looks only in the current directory for login.sql"

Not true per this snippet from the SQL*Plus User's Guide and Reference:

SQL*Plus also supports a User Profile, executed after the Site Profile. This file is
generally named login.sql. SQL*Plus searches for the user profile in your current
directory, and then the directories you specify with the SQLPATH environment
variable. SQL*Plus searches this colon-separated list of directories in the order
they are listed.

The logic of the bonus code stated on previous pages is not the logic contained in
the nested case statement on page 98 (in the 6/04 print version), but the first
paragraph implies that it is.

This statement should (as far as I can tell) read either:

CASE
WHEN salary > 40000 THEN
give_bonus(employee_id, 500);
WHEN salary >= 10000 THEN
CASE
WHEN salary <= 20000 THEN
give_bonus(employee_id, 1500);
WHEN salary > 20000 THEN
give_bonus(employee_id, 1000);
END CASE;
WHEN salary < 10000 THEN
give_bonus(employee_id, 500);
END CASE;

or:

CASE
WHEN salary >= 10000 THEN
CASE
WHEN salary <= 20000 THEN
give_bonus(employee_id, 1500);
WHEN salary > 40000 THEN
give_bonus(employee_id, 500);
WHEN salary > 20000 THEN
give_bonus(employee_id, 1000);
END CASE;
WHEN salary < 10000 THEN
give_bonus(employee_id, 500);
END CASE;

The FOR phrase in the sytax description is shown as

FOR record_index IN [cursor_name, (explicit SELECT statement)]

But the intent is that you must supply either a cursor name or an explicit SELECT,
so, based on the conventions, this should read:

FOR record_index IN {cursor_name |(explicit SELECT statement)}

Here is an example of declaring a numeric datatype that can have only one of three
values (1, -1, and NULL):

I think that sentence "INSTR2 works like INSTR4, but allows you to search for UCS-4
code units" should be: "INSTR2 works like INSTR4, but allows you to search for UCS-2
code units.

When describing the formating of TIMESTAMP variables the text claims that the time
can be specified to the millisecond, but the example output shown below it (and on
the next 2 pages) has the time displayed to the nanosecond. It also appears from the
examples that the default timestamp precision is to the microsecond (as shown below
the text in question and on page 285).

The example shows:

TYPE mishmash_rectype ...
(emp_number (10) NOT NULL...

However, on P327, it is stated "... a field in a record be NOT NULL
(in which case you must also assign a default value"
There is no default value specified in this example.

Color_array_t has not been introduced.
should be:
Color_tab_t

Text tells us we must use DBMS_LOB.FILEOPEN and DBMS_LOB.FILECLOSE when accessing
BFILEs. Code then uses DBMS_LOB.OPEN and DBMS_LOB.CLOSE. Don't know which is correct
(all 4 are in the DBMS_LOB package).

Description for SQL%NOTFOUND is incorrectly a copy of SQL%FOUND.

The code reads:

RETURN level_out;

It should read:

RETURN retval;

References to the cursor "major_polluters_cur" in the main body of the code is
missing the "_cur" from the end of the identifier,

i.e.
names (major_polluters%ROWCOUNT) := bad_car.NAME;
should read
names (major_polluters_cur%ROWCOUNT) := bad_car.NAME;

Or, remove the _cur from the declaration as in the example on the following page.

The select statement is wrong:

the example query reads:

SELECT name, mileage
FROM transportation
BULK COLLECT INTO names, mileages
WHERE TYPE = 'AUTOMOBILE'
AND mileage < 20;

The 'BULK COLLECT clause is out of place. It should read:

SELECT name, mileage
BULK COLLECT INTO names, mileages
FROM transportation
WHERE TYPE = 'AUTOMOBILE'
AND mileage < 20;

The sentence reads "The scope of a cursor variable is the same as that of a static
cursor: the PL/SQL block in which the variable is declared (unless declared in a
package, which makes the variable globally accessible).

The parenthetical portion of the sentence appears to contradict the first bullet
point under "Cursor Variable Restrictions" on page 530:

"Cursor variables cannot be declared in a package because they do not have a
persistent state."

This is supported by the Oracle documentation:

.PLS-00994 Cursor Variables cannot be declared as part of a package

Cause: An attempt was made to declare a cursor variable in a package specification,
which is not allowed. Although REF CURSOR types can be defined in a PL/SQL block,
subprogram, or package, cursor variables can be declared only in a block or
subprogram.

Action: Move the cursor variable declaration into a PL/SQL block or subprogram..

I think the authors meant to say that the REF CURSOR type could be define in the
declaration section of the package body (which would make it available globally).
However, the declaration of the actual cursor variable must table place within a sub-
block of the package body.

Unless I misunderstand, the binding code sample at the bottom of this page is wrong.
I'm referring to this snippet:

/* Binding */
EXECUTE IMMEDIATE
'UPDATE employee SET salary = :val
WHERE hire_date BETWEEN :lodate AND :hidate'
USING v_start, v_end;

Shouldn't v_sal be in the USING list? That is, I think the code should read:

/* Binding */
EXECUTE IMMEDIATE
'UPDATE employee SET salary = :val
WHERE hire_date BETWEEN :lodate AND :hidate'
USING v_sal, v_start, v_end;

The first sentence of bullet reads, "The following BEFORE INSERT trigger captures
audit information for the CEO compensation table." while the trigger code clearly
shows it as an AFTER INSERT trigger.

PRINT VERSION:
WHEN ((OLD.salary != NEW.salary OR
(OLD.salary IS NULL AND NEW.salary IS NULL))
OR (OLD.commission != NEW.commission OR
(OLD.commission IS NULL AND NEW.commission IS NULL)))

SHOULD BE:
WHEN ((OLD.salary != NEW.salary OR
(OLD.salary IS NULL AND NEW.salary IS NOT NULL) OR
(OLD.salary IS NOT NULL AND NEW.salary IS NULL))
OR (OLD.commission != NEW.commission OR
(OLD.commission IS NULL AND NEW.commission IS NOT NULL) OR
(OLD.commission IS NOT NULL AND NEW.commission IS NULL)))

In print, the example for set_score is incorrect, and should be changed to that given
in the downloaded examples.

The first SQL*Plus INSERT INTO command should not raise an exception at all. The
frame being inserted is not designated as either a strike or a spare. The score of 5
should be perfectly acceptable. In addition, the error message in the printed
version can only apply when the value for the "strike" column is specified as 'Y'.
Furthermore, the error text
Score For Strike Must Be Less >= 10
doesn't make sense, nor was it defined in the preceding narrative.

As for the second SQL*PLUS INSERT INTO command...

PRINT VERSION:
ORA-20001: ERROR: Score For Strike Must >= 10

SHOULD BE:
ORA-20001: ERROR: Score For Strike Must Be >= 10