The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".
The following errata were submitted by our customers and approved as valid errors by the author or editor.
| Version |
Location |
Description |
Submitted By |
Date submitted |
Date corrected |
| Printed |
Page back
ISBN number above the barcode |
ISBN number above the barcode contains a transposition of digits.
It starts 0-569 and should start 0-596.
|
Anonymous |
|
|
| Printed |
Page 35
Figure 3-2 |
In the USER_ROLES part of the diagram, it appears that a field is missing.
There should be a USER_ID field there.
the USER_ID field is included in Figure 3-5, page 38
p. 49, Example 3-6: Remove the 9th and 10th lines ("DROP TABLE ATTENDEES;"
and "DROP TABLE EVENTS;") from the example, as they are duplicates.
p. 85, Example 5-7: Near bottom of page, change the method signature for
getNextValue() from "public int getNextValue(String keyName) throws
SequenceException {" to "public Integer getNextValue(String keyName) throws
SequenceException {"
p. 89, Example 5-9: The line "public class OfficeBean extends
EntityAdapter {" should read "public abstract class OfficeBean extends
EntityAdapter {"
|
Anonymous |
|
|
| Printed |
Page 169
FROM READER: example 8-7 |
Using floating point datatypes for representing monetary values is a serious error
that can result in accounts not quite balancing once in a while; due to floating
point representation issues the rounding doesn't work exactly the way you might
expect. Your example code uses a float in the database creation ddl for money
amounts, and also uses the java float primitive to pass the money amounts back to the
client.
One safe way to do this is to use a fixed-point numeric type in your DDL, the EJBs
can use a BigDecimal value for the amount. (if you don't want to be sending
bigdecimals over the wire and back all the time you can convert the bigdecimal to an
integral type, just avoid using float.)
FROM AUTHOR: These comments are exactly right, in the sense that a float, over long
amounts of time (re: years) can sometimes cause odd results. However,
there is no _consistent_ way to handle money that is better. While some
databases support a fixed-point numeric value, others do not. You have
a huge variance, and using a float is the only non-proprietary way to
handle this.
That said, if you are targeting a specific database, and have no
concerns about porting, then I would indeed recommend consulting the
database's documentation and looking at specific types that that
particular database uses for monetary values.
|
Anonymous |
|
|
| Printed |
Page 216
Example A-13 |
In the EVENTS table, the DATE_TIME column is created as a DATE type. In MySQL, DATE
types only store year, month and day. Use the DATETIME type instead, to store year,
month, day and time. (Note: I encountered a serialization error due to this problem
when using JBoss 3.0.3 and MySQL 3.23.52.)
AUTHOR: Yeah, confirm this.
p. 217, Example A-16: After the first line (A comment), and before all
"DROP" statements, add the following two lines:
DROP TABLE ATTENDEES;
DROP TABLE EVENTS;
p. 218, Example A-17: After the fourth line (A comment), and before all "e
DROP" statements, add the following two lines:
e DROP TABLE ATTENDEES;
e DROP TABLE EVENTS;
p. 218, Example A-18: After the first line (A comment), and before all
"DROP" statements, add the following two lines:
DROP TABLE ATTENDEES;
DROP TABLE EVENTS;
p. 218, Example A-19: After the first line (A comment), and before all
"DROP" statements, add the following two lines:
DROP TABLE ATTENDEES;
DROP TABLE EVENTS;
p. 219, Example A-20: After the first line (A comment), and before all
"DROP" statements, add the following two lines:
DROP TABLE ATTENDEES;
DROP TABLE EVENTS;
p. 220: Example A-21: In each line of the script, the word "SEQUENCES"
should be changed to "PRIMARY_KEYS"
p. 220, Example A-22: In each line of the script, the word "SEQUENCES"
should be changed to "PRIMARY_KEYS"
p. 221, Example A-23: In each line of the script, the word "SEQUENCES"
should be changed to "PRIMARY_KEYS"
p. 221, Example A-24: In each line of the script, the word "SEQUENCES"
should be changed to "PRIMARY_KEYS"
p. 222, Example A-25: In each line of the script, the word "SEQUENCES"
should be changed to "PRIMARY_KEYS"
|
Anonymous |
|
|
| Printed |
Page 222
Change the title of A-Head "Creating Types" to "Inserting Types" |
|
Anonymous |
|
|
| Printed |
Page 226
2nd para. Change (in last sentence) the word "ForethoughtDB" to |
read "forethoughtDB", and italicize the word.
|
Anonymous |
|
|
| Printed |
Page 226
last para: Change the script name from "database_schema_users.sql" |
to "cloudscape_createUsers.sql".
|
Anonymous |
|
|
| Printed |
Page 226
info block: Change the script name from "database_schema_keys.sql" |
to "cloudscape_primaryKeys.sql".
----- 229 -----
p. 229, 1st para: Change the two parenthetical file references from
"database_schema_users.sql" to "instantDB_createUsers.sql" and
"database_schema_accounts.sql" to "instantDB_createAccounts.sql".
p. 229, main code sample: Change the filename on the second line from
"database_schema_usrs.sql" to "instantDB_createUsers.sql"
p. 229, 2nd to last para: Change the script name from
"database_schema_accounts.sql" to "instantDB_createAccounts.sql".
p. 229, last para: Change the script name from "database_schema_keys.sql"
to "instantDB_primaryKeys.sql" and from "database_schema_createTypes.sql" to
"instantDB_insertTypes.sql"
p. 230, main code block: Change the line "mysql> source
database_schema_users.sql" to "mysql> source mySQL_createUsers.sql", and
change the line "mysql> source database_schema_accounts.sql" to "mysql>
source mySQL_createAccounts.sql".
p. 231, code block: Change the line "SQL> @database_schema_users.sql" to
"SQL> @oracle_createUsers.sql"
p. 232, top code block: Change the line "SQL>
@database_schema_accounts.sql" to "SQL> @oracle_createAccounts.sql".
p. 232, 2nd para: Change the script names from "database_schema_keys.sql"
to "oracle_primaryKeys.sql" and from "database_schema_createTypes.sql" to
"oracle_insertTypes.sql".
p. 232, bottom code block: Change the line "SQL>
@database_schema_keys.sql" to "SQL> @oracle_primaryKeys.sql".
p. 234, code block: Change the top line script name
"database_schema_users.sql" to "postgreSQL_createUsers.sql".
p. 242, bottom example: Remove the single quotes from around "cn" and
"description" (last two lines of sample).
p. 243, middle code sample: Remove the single quotes from around
"uniquePermission" (last line)
p. 244, main code sample: Replace the entire sample with this newer
sample:
# Initialization
dn: dc=forethought,dc=com
dc: forethought
o:Forethought
objectClass: organization
objectClass: dcObject
dn: cn=Manager,dc=forethought,dc=com
cn: Manager
sn: Manager
objectClass: person
# People organizational unit
dn: ou=People,dc=forethought,dc=com
ou: People
objectClass: organizationalUnit
# Groups organizational unit
dn: ou=Groups,dc=forethought,dc=com
ou: Groups
objectClass: organizationalUnit
# Permissions organizational unit
dn: ou=Permissions,dc=forethought,dc=com
ou: Permissions
objectClass: organizationalUnit
|
Anonymous |
|
|
| Printed |
Page 253
Example E-6, UserInfo constructor |
The UserInfo constructor as written will throw a NullPointerException when the
officeInfo parameter is null. Since clients will not have offices we must protected
ourselves against this situation:
if (officeInfo != null)
{
this.officeCity = officeInfo.getCity();
this.officeState = officeInfo.getState();
}
|
Anonymous |
|
|