I have so far read chapter 6, and to be very frank, I am not impressed. Note that my review is very technical, requring good understanding of SQL Server, Microsoft DNA and MTS. Unless you already understand these topics well, you may not find my review useful.
I have listed a few problems with the author's code (just in Chapter 6).
(1) In its Order_Place stored proc, the code calls exec Orders_Add, and then exec OrderDetails_Add procs. After calling both procs, the author tests @@error=0 to decide whether to commit or roll back transactions.
If there is an error in Order_Add, but not in OrderDetails_Add, then @@error would still be 0 (noting that @@error would be set by the last statement), and thus the code could commit despite inconsistencies.
(2) Still in the Order_Place proc, the author called begin tran/commit tran/rollback tran SQL statement. This proc is meant to be used by MTS/COM+, and thus should leave transaction handling to MTS.
(3) In Products_UpdStock proc, author raises an error if @UnitsInStock < @Quantity, without exiting the proc. Now if it weren't for the fact that Northwind database has a constraint requiring UnitsInStock>=0, this proc would have continued on to update UnitInStock despite Quantiy required > UnitsInStock. The author doesn't seem realize RaisError does not exit proc.
(4) The author uses Northwind_Order.Order class to place an order. This is a business logic layer module. It in turn calls Data.Access module, which is in the Data Access Layer. As the author pointed himself, the idea of having separate data access layer and business logic layer is so that if ever, the underlying database changes, only data access layer has to be recoded, thus improving maintainability. This is the one of the tenors of Microsoft DNA. However, in author's Northwind_Order.Order class, it actually constructs a SQL string that is in turn passed to Data.Access. If the underlying database is changed from SQL Server to Oracle, the author would have to rewrite both his Northwind_Order.Order class and Data.Access because Oracle has a totally different convention of writing stored proc.
These problems are just from cursory glances that I have taken at Chapter 6. I can't be sure how the rest of the book stacks up.
