The author is obviously obsessed with Stored Procedures and makes a very good case for using them. In his systems, every application deals only with stored procedures and never performs SQL statements directly. Well, that's one way of doing it, but it introduces a whole lot of problems that were never really discussed too clearly.

The book is an excellent resource not just for the theory but for practical code snippets you can [take] and use in your next huge, huge enterprise application.

I say "huge, huge", because the sheer amount of overhead you will create in developing any applications based on this architecture is astounding. For anyone who started programming in COBOL, welcome to the world of Microsoft object-oriented programming! You will be spending 90% of your time worrying about coding things that have absolutely nothing to do with the application! Do we really want our application subject matter experts to have to worry about Shared Properties Managers, Object Construction, Threads, Object Pooling? Well, we have no choice if we go with .NET under Microsoft.

If you've stepped away from VisualBasic for a couple of years, welcome back to the new world of Microsoft's vision for a single language with many names. They call it VisualBasic now, but it's just C wearing a mask. Forget about rapid coding. Forget about type-independence. Forget about functions and subroutines. You're going to be spending most of your time memorizing the wall chart of COM objects and trying to learn yet another incarnation of VB that is as incompatible with the previous version as Java is with Fortran.

Don't believe me? OK, use Visual Studio.NET to write a simple application that looks up a record in a table and says "Hello World".

But I digress. The book's treatment of error handling, trace logging, concurrency locking, and other oft-neglected issues is very good and gives practical advice on how to do it. I will personally implement many of his suggestions. Many others I will pare down into a more manageable architecture for a company that does not have a multi-million dollar IPO worth of cash to burn through in the next 12 months.

His critical analysis at the end of each chapter of the proposal presented in that chapter, on the basis of performance, scalability, portability, maintainability, reusability, testability, debuggability, interoperability, and other "ities" was very clever. I will use that, as well as "codability", "readability", "longevity", and "learning curve" to help evaluate what language I want to use in my next application. It might show an MS OO language to be the worst choice. Who knows?

2 pet peeves:

1. "Preventive" is the correct word. There is no such thing as "Preventative", because we do not preventate things. Wonder how that slipped past the spell checker that SURELY every writer nowadays has.

2. "Errand" is running to the store to get something. "Errant" is something that has gone wrong. The entire sample application is built on a misuse of the word "Errand". But I forgive Jimmy because he is Swedish, and if I had to write a technical book in any of my 2nd languages, I would be hard pressed to get absolutely everything right.

Good job, Jimmy.