MySQL Stored Procedure Programming, First Edition by Guy Harrison with Steven Feuerstein The unconfirmed error reports are from readers. They have not yet been approved or disproved by the author or editor and represent solely the opinion of the reader. Here's a key to the markup: [page-number]: serious technical mistake {page-number}: minor technical mistake : important language/formatting problem (page-number): language change or minor formatting problem ?page-number?: reader question or request for clarification This page was updated June 16, 2008. UNCONFIRMED errors and comments from readers: (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()", 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. (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. (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). {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." {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 (127) 1st paragraph; "...set the variable p_status to ..." should be "...set the variable out_status to ..." (141) 1st paragraph; "...ability to display the SQLSTATE or SQLSTATE..." should be "...ability to display the SQLCODE or SQLSTATE..." (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, ..." (186) Example 8-3, line 8; Drop 'sp_' from 'sp_location_exists'. Later reference is to 'location_exists'. (201) Example 8-12, line 59; END$$ should read: END; {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: ...) {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); ^^^ {348} Examples 15-7, 15-8; (1) $dbh->commit is missing in both examples for the already discussed value of $dbh- >{AutoCommit} = 0 (2)(from the Perl DBI documentation) --- snip ---------------------------------------------------- The recommended way to implement robust transactions in Perl applications is to use RaiseError and eval { ... } --- snip ----------------------------------- [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}; (463) Line 1; The chapter begins "In this chapter, we will tune of simple SQL statements...", which doesn't make sense. Is "of" superfluous? [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.