The errata list is a list of errors and their corrections that were found after the product was released.
The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.
| Version |
Location |
Description |
Submitted By |
| Printed |
Page 1
$dbh->commit is missing in both examples for the already discussed value of $dbh- |
>{AutoCommit} = 0
|
Anonymous |
| Printed |
Page 2
(from the Perl DBI documentation) |
--- snip ----------------------------------------------------
The recommended way to implement robust transactions in Perl applications is to use
RaiseError and eval { ... }
--- snip -----------------------------------
|
Anonymous |
| Printed |
Page 25
Screenshot |
The cursor was left on the page when the screen shot was taken, which makes these illustrations
sometimes confusing or hard to read. For instance, on page 32, you cannot tell if it is
"simple_loop()", "simple_loop(<something unintelligible>)", or "simple_loop)", and when first
learning the syntax of something, I think you need clearer examples.
This happens on 25, 27, 28, 29, 32, 34, 35, 36, 38, 42, 160, 164. In the early part of the book,
there are places where it is difficult to see parenthesis and such due to cursor or insert point,
or sometimes a selected character as if in the middle of a cut-and-paste operation.
|
Anonymous |
| Printed |
Page 34
Example 2-6 |
The procedure defined in Figure 2-10 defines total_sales
to be type NUMERIC(8,2); however when the result is printed
out the value is displayed as 7 digits before the decimal
place and none after it - a NUMERIC(8,2) would have up to
six characters before the decimal point and 2 after it,
which means that the result doesn't even fit in the variable
and it displays as 999999.99!
Also, using the example database, I got the answer:
Total sales for 2 is 7270844.00
which is different from the answer printed in the book.
|
Anonymous |
| Printed |
Page 40
line 30 |
Stored procedure CALLs for 1_new_salary procedure. I can't find how to create this stored
procedure.
Also, on page 41, example 2-8 CALLs cursor_example2(18) instead of putting_it_all_together(18).
|
Anonymous |
| Printed |
Page 52
1st paragraph |
Text says:
"So 2.4e is equivalent to 2.4 x 10 4 or 24,000." (Of course, I cannot superscript the '4' after the
'10.)
It should read:
"So 2.4e4 is equivalent to 2.4 x 10 4 or 24,000."
An even better example would be:
"So 2.3e4 is equivalent to 2.3 x 10 4 or 23,000."
|
Anonymous |
| Printed |
Page 64
final example in section |
Where bitwise operators are explained, the following example is given
The bitwise AND operator sets a bit only if both the bits are true in the input. So 5&6=7, because
101&110=111, which equals 4.
101&110=111 should of course read 101&110=100 and 5&6=7 should read 5&6=4
|
Anonymous |
| Printed |
Page 127
1st paragraph |
"...set the variable p_status to ..."
should be
"...set the variable out_status to ..."
|
Anonymous |
| Printed |
Page 141
1st paragraph |
"...ability to display the SQLSTATE or SQLSTATE..."
should be
"...ability to display the SQLCODE or SQLSTATE..."
|
Anonymous |
| Printed |
Page 148
Example 6-23 |
line 33:
SET p_sqlcode=1052;
should be:
SET p_sqlcode=1062;
|
Anonymous |
| Printed |
Page 173
Line 16 (including paragraph headings) |
The book says "IF EXISTS is only valid for stored procedures
and triggers, not for triggers", which seems a bit self-contradictory.
Presumably it should say "... only valid for stored procedures and
functions, ..."
|
Anonymous |
| Printed |
Page 186
Example 8-3, line 8 |
Drop 'sp_' from 'sp_location_exists'. Later reference is to 'location_exists'.
|
Anonymous |
| Printed |
Page 201
Example 8-12, line 59 |
END$$ should read: END;
|
Anonymous |
| Printed |
Page 346
Example 15-1 |
Strict should be all lowercase, e.g.,
use strict;
use DBI;
otherwise call results in
Can't locate Strict.pm in @INC (@INC contains: ...)
|
Anonymous |
| Printed |
Page 348
Example 15-7 |
In perl the concatenation operator is '.' not '||' (as in SQL) ;-)
Example 15-7 should read
$sth->bind_param(2, 'Row# ' . $i);
^^^
|
Anonymous |
| Printed |
Page 348
Examples 15-7, 15-8 |
|
Anonymous |
| Printed |
Page 352
Example 15-17 |
Maybe it should be clarified that the returned TYPE attribute are integers and correspond to some
international standards. Maybe an example how to translate them would be great.
my $translated = $dbh->type_info( $type )->{TYPE_NAME};
|
Anonymous |
| Printed |
Page 463
Line 1 |
The chapter begins "In this chapter, we will tune of simple SQL statements...",
which doesn't make sense. Is "of" superfluous?
|
Anonymous |
| Printed |
Page 567-568
Dynamic SQL Example - bind order |
The example SQL code appears to get "in_where_val" and "in_set_val" mixed up.
While the code is "technically" correct, it definitely does not follow best practices illustrated earlier in the same chapter.
If you look at the input parameters:
(in_table varchar(60),
in_where_col varchar(60),
in_set_col varchar(60),
in_where_val varchar(60),
in_set_val varchar(60))
And compare that with your sample:
CALL update_anything_g('employees','employee_id','salary',100000,1)
Judging by the way the variables are named, it would seem that you are going to update the salary = 1 where the employee_id = 100000.
But in fact, the procedure works as intended because your items are in the wrong order in the USING clause:
'UPDATE employees SET salary = ? WHERE employee_id = ?'
EXECUTE s1 USING @where_val,@set_val;
So your procedure works because you know the correct order for submitting variables. However, as far as self-documenting code goes - any future developer is going to really be confused using this procedure because they are probably going to first submit the data logically according to the input parameter labels.
|
Anonymous |
| Printed |
Page 607
SUBSTRNG |
typo SUBSTRNG
should be SUBSTRING
|
Anonymous |
