Database Developers Guide w/Delphi 2|K. Henderson 0672308622

||boek: Database Developers Guide with Delphi 2|Design, Develop, and Deploy 32-bit Database Applications!|SAMS|Borland Press

||door: Ken Henderson

||taal: en
||jaar: 1996
||druk: 1st edition
||pag.: 857p
||opm.: paperback|like new|with CD

||isbn: 0-672-30862-2

This is a 1st edition!

||code: 1:000636

--- Over het boek (foto 1): Database Developers Guide with Delphi 2 ---

Focusing on advanced database development, this work details the intricacies involved in developing robust database applications with Delphi.

[source: https--www.goodreads.com]

The only book to focus on advanced database development, readers will learn the intricacies involved in developing robust database applications with Delphi.

• Comprehensive coverage of how to create distributable database applications
• Explains all of Delphi's database development tools
• CD-ROM includes all of the source code from the book, sample applications, and demo software

[source: https--www.amazon.com]

Rotten tutorial [2001-12-18]

I do not like writing negative book reviews (see other books I have reviewed) but I feel I have to in this case.

I bought this book because a major portion of the book (Chapters 8 to 14) goes through a tutorial of developing a database application using Delphi. I quickly ran into problems.

1. In many cases, what the book says and the illustrations do not match. This can be very confusing. In most cases, follow what the book says (exception: Chapter 9 - the editform where the illustration is correct; I believe a paragraph has been deleted here.)

2. The author's style of writing is verbose. It would be much easier if steps were written in a 1-2-3 manner so that it is easy to follow rather than putting everything into essay form. If you were spending a half hour a day or so working through the book, it can be very difficult to pick up where you left off. Also in the future if you want to refer to something, it is very difficult to look it up.

3. (personal opinion) I happen to disagree both with the author's user interface and with his method of data modeling.

4. There is a CD with the book which supposedly has all the source code from the book. This would be a good place to check the typographical errors and to see a complete finished product with all the code. Unfortunately the finished product does not work, the code in the CD has no resemblance whatsoever to what was in the tutorial.

On the bright side, I like his naming conventions for objects (Chapter 4). Also one of the few books I have come across that goes through report writing in some detail (Chapter 12) and the Control Grid component (user beware: the control grid component comes with the developer's edition of Delphi, not the desktop edition).

If you are really interested in database programming with Delphi, and are willing to take the time and spend the effort to do it right, I would recommend that you get:

1. A good book on database design (eg. "An introduction to database systems" by Date, "Data Analysis for Data Base Design" by Howe)

2. A good book on user interface design

3. A good book on Delphi techniques (eg. "Mastering Delphi" by Cantu)

I. Chanthiran [source: https--www.amazon.com]

Excellent tutorial [2002-02-04]

I don't write many good technical book reviews. Most books just don't deserve it. This one, however, is an exception.

I bought this book because a good portion of it is dedicated to a tutorial that shows how to develop a complete database application using Delphi. I have never seen such a detailed, complete tutorial in a technical book. It spans some seven chapters and takes you from literally nothing but a concept of what the application might to do a polished product. I've never seen anything like it in a book before.

Some highlights:

1. The interleaving of the figures and commentary is excellent. It feels like you've got the instructor right there in the room with you. You get the sense that the author has built an application or two.

2. The prose is friendly, yet nitpickingly technical and complete. Useful tips abound. Usually, you don't get both technical excellence and good writing in the same computer book. Not true with this one. This is some of the best technical writing I've ever read.

3. The approach taken to show user-interface design is right on the money. It's better than many books dedicated to the subject. Henderson apparently comes from the same school of thought as Microsoft. His recommendations follow those of the book "The Windows User Interface Guidelines for Software Design" (from Microsoft Press), though his book predates this book.

I also really love his approach to database design and data modeling. It is a nice cross between the approach C.J. Date's books take (e.g., Foundation for Future Database Systems - Addison-Wesley) and those of Joe Celko (e.g., Data and Databases - Morgan-Kaufmann). His approach is practical, yet grounded in solid theory. Here is a database wiz who knows both sides of the business -- the high-brow theory and the stuff that pays the bills.

4. The CD is a great value in and of itself. In addition to providing the full source code for the book (there must be thousands of lines of it), it also contains a number of extra utilities and components that have value a part from the book. I would have paid what I did for the book just to get the CD.

The book is simply a masterpiece that has stood the test of time. The naming conventions chapter, the report writing chapter, the chapter on the BDE, the one on creating your own data-aware components, etc., make for some of the best technical writing out there on Delphi or any other language tool.

If you are really interested in database programming with Delphi, this is the one book to have. It tells you everything you need to know to build robust, scalable, polished Delphi applications for the complex world of Windows.

I liked this one so much that I recently paid big $$ to get the sequel to this book (Client/Server Developer's Guide with Delphi) from a collector. I'll post a review of it as soon as I finish going through it. Already I'm learning tons.

One last comment: I loved the Epilogue. No one has ever said it better!

Buck F. Channoy [source: https--www.amazon.com]

A classic that I turn to again and again [2001-02-20]

I got on here to see if maybe this book had been updated and was saddened to learn that it has not been. Oh well, no matter - I'll just keep using the one I have.

I have to admit, my copy is getting pretty worn. The back cover was lost long ago and the front probably won't make it through the year. Why? The book is a masterpiece. You don't see readable prose and precise detail like this anymore. You don't find breadth and depth in the same computer book these days. I take it with me everywhere I go.

What I like most about the book is that it's laden with experience. Obviously, the author has been around the world a time or two as a developer. He knows his stuff because he has been there, a fact you can't miss if you read the book through.

All in all, if you want to learn database development in Delphi from a master, look no further - this is the book for you. Nevermind that it was written for D2 - it's just as applicable today as it was when D2 first came out.

Penned by a veteran software engineer who writes prose as well as writes code, this is the one book to have if you want to know Delphi database development inside out.

Thomas G. [source: https--www.amazon.com]

The best Delphi book I have found [2002-02-07]

I have all the Delphi books out there - Cantu, Calvert, etc. - and none of them compare to this one. It's written better than 99% of the technical books you will find. It is also jam-packed with useful technical info. No other Delphi book compares. The best things about this one are:* Detailed instructions on connecting to and working with the leading DBMSs. Just the other day this saved my behind with an Oracle problem I was having.* The components chapter. I couldn't believe how easy it was to make data bound components.* The tutorial. I worked through this and learned oodles of things that I didn't know about Delphi (I've been using Delphi since version 2).It's just a great book that belongs in your library if you're serious about Delphi.

User [source: https--www.thriftbooks.com]

A classic that I turn to again and again [2001-02-21]

I got on here to see if maybe this book had been updated and was saddened to learn that it has not been. Oh well, no matter - I'll just keep using the one I have.I have to admit, my copy is getting pretty worn. The back cover was lost long ago and the front probably won't make it through the year. Why? The book is a masterpiece. You don't see readable prose and precise detail like this anymore. You don't find breadth and depth in the same computer book these days. I take it with me everywhere I go.What I like most about the book is that it's laden with experience. Obviously, the author has been around the world a time or two as a developer. He knows his stuff because he has been there, a fact you can't miss if you read the book through.All in all, if you want to learn database development in Delphi from a master, look no further - this is the book for you. Nevermind that it was written for D2 - it's just as applicable today as it was when D2 first came out.Penned by a veteran software engineer who writes prose as well as writes code, this is the one book to have if you want to know Delphi database development inside out.

User [source: https--www.thriftbooks.com]

A Delphi Classic [2000-07-21]

I found this book at a local bookstore and had heard good things about Henderson's work, so I bought it. I wasn't disappointed. I've now worked through the entire book and have learned ALOT about Delphi -- including many things I didn't even know were there. Even though Delphi itself has changed quite a bit since D2 (and hence the screen shots don't always match up with the text), this book is truly timeless. I ran into a few minor problems relating to version differences (e.g., Database Desktop is no longer a menu item in Delphi like it was in D2), but nothing major. 90% of what you learn from this book applies to every version of Delphi. Highly recommended. If you can find one, get a copy and read through it cover-to-cover.

User [source: https--www.thriftbooks.com]

A homerun as far as I'm concerned [2000-05-15]

I picked this up at a bookstore recently and felt compelled to get on here and write about what I'd found. I've been developing in Delphi since v1, but for some reason, I'd never come across this book. I was building a new app in D5 for the Internet and wanted to find a good foundational reference for databases from the perspective of Delphi. I happened upon this book, and, boy, was I blown away! Given that it was targeted at D2, I couldn't believe that it would still apply to D5, but it does indeed. The tutorial section, where the author leads you by the hand from app concept to app deployment is the best I've seen. The performance & tuning section teaches a few tricks even an old dog like me hadn't seen before. The author has obviously been in the trenches a time or two. All in all, this is a great book that I wish I'd bought when it first came out. I shudder to think how much time it could have saved me.

User [source: https--www.thriftbooks.com]

Excellent book for learning database programming in DELPHI [1998-11-27]

I can say that I am very happy I bought this book, because this was my entry point to the world of DELPHI. This book explain (very detail), all steps necessary for completing a database application. The first step: database design, then creating database objects (tables and queries etc.) and finally building a DELPHI application based on the database. What I dislike about this book is, that the author uses PARADOX database that is not very popular in the database world. He could use ACCESS database for example, or client-server oriented database server. I wonder why the author dedicated to client-server database application a small part of this book, according to large part dedicated to single-user database application. Anyway, this is an excellent book for those who want to learn how to build a database application starting from scratch.

User [source: https--www.thriftbooks.com]

Learn the intricacies involved in developing robust database applications with Delphi. Since Delphi represents new ways of doing many database tasks, most developers, however experienced they might be with other tools, will need help getting up to speed developing database applications with Delphi.

[source: https--books.google.be]

--- Over (foto 2): Ken Henderson ---

Ken Henderson, a nationally recognized consultant and leading DBMS practitioner, consults on high-end client/server projects for such customers as the U.S. Air Force, the U.S. Navy, H&R Block, Travelers Insurance, J.P. Morgan, the CIA, Owens-Corning, and CNA Insurance. He is the author of five previous books on client/server and DBMS development, a frequent magazine contributor to such publications as Software Development Magazine and DBMS Magazine, and a speaker at technical conferences.

[source: https--www.informit.com/authors/bio/557445a0-92da-4134-a2bd-04f3600b701b]

SQLAuthority News - RIP: Ken Henderson, 1967 - 2008 [2008-02-10]

SQL, SQL Server, SQL Tips and Tricks, SQLAuthority News

Ken Henderson, a nationally recognized consultant and leading DBMS practitioner, consults on high-end client/server projects [passed] away on Sunday, January 27, in Meeker, Oklahoma. Ken was an inspirational author of the SQL Server Guru's Guide series of books. We will miss his forever. He was the author I respected the most.

I have reviewed his book SQLAuthority News - Book Review - SQL Server 2005 Practical Troubleshooting: The Database Engine earlier on this blog. That was one great book. You can read sample chapter from that book here.

Let us read first sentences of last two of his personal blog. Besides great teacher he was great observer of life too.

"I've tried to live my life without regrets, ..."

"Today's song is: "The Future Is Not What It Used To Be ..."

Rest In Peace - Ken Henderson.

Reference: Pinal Dave (https--blog.sqlauthority.com), Ken Henderson

Pinal Dave [source: https--blog.sqlauthority.com/2008/02/10/sqlauthority-news-rip-ken-henderson-1967-2008]

Geek of the Week - Ken Henderson [2005-04-25]

Ken is a consultant who often works for high-profile customers, including the U.S. Navy and Air Force, as well as H&R Block. In addition to books, Ken writes articles covering all aspects of SQL Server.

An interview with Ken Henderson

I have never met Ken Henderson, but I have followed his career, read his books, and even reviewed one or two of them for Dr. Dobb's Journal. When I first saw Ken's The Guru's Guide to Transact SQL I almost did not pick it up. As a general rule, I don't pick up the guru's guide to anything. I'm glad I overcame this, since the book is little short of amazing.

Ken surprised me again with his latest book, The Guru's Guide to SQL Server Architecture and Internals . About 400 pages into it, I was impressed by the introduction to what is involved in creating a server-based application, but wondered about its inclusion in a SQL Server book. The next 400 pages made it clear that understanding how servers work on Windows is critical to understanding the implications of how SQL Server runs.

The fact that I was impressed with the book's server coverage is particularly noteworthy, as I have written a book on server-based applications myself !

Ken is a consultant who often works for high-profile customers, including the U.S. Navy and Air Force, as well as H&R Block. In addition to books, Ken writes articles covering all aspects of SQL Server, especially the low-level details that can trip up all but the most intense database geek. A recent MSDN article of Ken's, and one that he is uniquely qualified to write, covers the perils of fiber mode . It is a rare person who is at home with both the intricacies of Transact SQL as well as the details of Win32 I/O completion ports. Even more rare is someone who has the ability to communicate this sort of information to his readers.

The question-and-answer session with Ken that follows was conducted via email.

Doug: For years interviewers have tried to ask edgy questions. This being a geek-related interview, I ask you, "Stored procedures or ad-hoc SQL? And why?"

Ken: I favor stored procedures for several reasons. First, they generally perform better. Stored procedures encourage plan reuse and leverage the optimizer's ability (I work mostly with SQL Server these days) to create efficient execution plans for carrying out user requests. Second, stored procedures encourage modularity in applications. You can update a stored procedure independent of the applications that use it as long as you keep its interface-what it expects and it returns-the same. You can't do that with ad hoc SQL. Third, stored procedures are more secure. Many SQL injection attacks occur because people use ad hoc SQL where they should instead use parameterized stored procedures.

Doug: When you program in .NET, do you favor VB.NET, C#, or some other language?

Ken: C#, hands-down. As a longtime C/C++ developer, I am at home in C#. It is really just another member of the C family of languages, and one that I wish had existed years ago. To a veteran C++ coder, it feels very much like a cleaned-up C++. Another reason I like it is because it was designed by Anders Hejlsberg, one of the top scientists in the industry, in my opinion. During his time at Borland, Anders also designed Delphi and every version of Turbo Pascal, so he is in my own personal pantheon of heroes.

For obvious reasons, people like to compare C# to Java, but I have a different perspective. As a longtime Delphi aficionado, I see a lot of similarity between C# and Delphi's Object Pascal language. I see a lot in common between the .NET Framework and the Delphi Visual Component Library. In fact, in many cases all you would need to do to translate a typical app between Delphi and C# is a series of simple find-and-replace operations. They're that similar. Given that the same person designed both Delphi and C#, and given Anders' influence on the Framework itself, it's not that surprising, but it's something that I don't think many people are aware of.

Before C#, I don't think Anders' work got the attention it deserved. Delphi was extremely popular for a year or two after its release, but that was soon superseded by Java and newer releases of the Microsoft language tools. It's good to see Anders finally get the credit he deserves, and it's good to see him in a position to help so many more developers with his unique take on what constitutes software elegance.

As for VB, I have to confess that I have never really liked the language. It has its place, I suppose, but by the time VB became really big, I was already using what I considered to be a superior general-purpose Windows language tool, Delphi, and have never looked back. In fact, until C# came out, I considered Delphi to be the best all-around development environment for Windows application development, bar none.

Until VB.NET, the Visual Basic language lacked true inheritance or polymorphism, and what OOP inclinations it had seemed to be mostly an afterthought. That all changed with VB.NET, though-it's a full-blown, powerful OOP language in the same way that the other CLR languages are. That said, I don't see any real reason to use it over C# in my own work, and I see several things that make me wonder whether that would even be wise.

For one thing, it is still weighed down with the historical baggage of the Visual Basic language. Things that take a single keyword in C# or J# take multiple keywords in VB.NET. Things that are consistent and orthogonal in C# are uneven and sometimes even a bit unwieldy in VB.NET. From my perspective, due to the necessity of maintaining some amount of compatibility with VB6 and earlier, VB.NET is not nearly as lean or as elegant a language as C#. I believe this also makes it more difficult to use.

Ironically, C#, the scion of the language with the most historical baggage of them all-meaning C-is a simpler and more concise language than VB.NET because it was able to more or less start with a clean slate. VB.NET, on the other hand, had a lot of external forces pressuring it to meet some arbitrary standard of backward compatibility and forcing things on it that would have been better left behind. Sadly, the very things that were bolted on to it to make older code easier to port may eventually be its undoing if they make it so onerous to use that C# becomes a more attractive option for people migrating apps from VB6.

Doug: Do you do much unmanaged code these days? That is, non-.NET, Win32 code?

Ken: For unmanaged code, I work pretty much in C++. Occasionally, I still get back to Delphi, but not as much as I'd like.

Doug: There have been a number of blog posts, even petitions, to bring back official Microsoft support for VB6. What are your thoughts on this?

Ken: It's really a shame that such a cottage industry grew up around VB6 and earlier and that so many people are now left with code that is difficult to port due to the language being cleaned up with VB.NET. Many of the changes to the language that have come out in VB.NET were long overdue but, of necessity, break existing applications. I'm all for the clean up and the changes I've seen in VB.NET and, if anything, I would have taken them further.

I'm actually fonder of the Visual Basic language now than I have ever been before. And I don't think I'm alone in that. A lot of experienced Delphi and C++ developers-people traditionally outside the VB camp-have taken a second look at VB.NET and come to the conclusion that it is, at long last, a real OOP language and that it's just as powerful as many others out there. What remains to be seen is whether there is a compelling reason for people like me to use VB.NET over C# and whether people porting code from VB6 would be better served going straight to C#.

I know a lot of people are feeling some pain due to the differences between VB6 and VB.NET, but extending support for VB6 is not the way to fix those things. Microsoft is already doing things to bring disaffected VBers back into the fold, which is a good thing, and I think the VB community has to take some responsibility itself.

The wisest course would be for VBers to look at the language more holistically, outside the context of whether the changes break existing apps or alter the way they're used to thinking about things. They should look at the evolution of the language as a whole and ask themselves whether the changes are best in the long run. In most cases, an informed and honest answer to this will be "Yes." And I think if we can get on the same page vis-à-vis whether or not the changes represent what's best for the language as a whole, we can then proceed with how best to migrate old apps to it.

Doug: How did you start out working on databases? What was your first database-related job?

Ken: I started working on databases on old mainframes and midrange computers before the PC existed. I guess the first real relational database I used was on the IBM System/38. I had written code for a few machines before that, but they had an assortment of non-relational data management systems such as flat-file DBMSs and hierarchical databases. My first database-related job was writing COBOL, BASIC and RPG for the System/38 in the early 80s.

Doug: How did you learn about databases?

Ken: Having written code for many non-relational databases, I was instantly struck by the logic, efficiency, and the all-around general coolness of the relational database the first time I coded for one. I was hooked. The System/38 was then, and still is, a great machine for its intended user base. Its successor, the AS/400, only furthered that. Believe it or not, it had features 20 years ago that DBMSs like SQL Server are just now getting.

When the PC came out, I began dabbling in PC programming and eventually in PC databases. The first one I worked with was dBase II, an old floppy-based DBMS from Ashton-Tate. (Years later, Ashton-Tate would partner with Sybase and Microsoft to help launch the first release of SQL Server for the PC.) dBase II had a lot of features for a PC program but was relatively slow because its programming language was interpretive. It was also prone to corruption because it was a PC app that often stored data on floppy disks.

From dBase II, I moved to dBase compilers such as WordTech's db2Compiler and, later, Quicksilver. Quicksilver produced native machine code, but was so tedious to use (it had some five separate "compilation"-type stages) that I wrote my own RAD-style development environment for it. That tool became the Cheetah Integrated Programming Environment, which was a popular multi-language development environment for the PC for a few years, and was especially popular for database application development.

I guess I've learned most of what I know about databases by building database applications and managing database systems. I've read plenty of books on the subject, but when I came through school, there wasn't much in the way of good instruction on databases, let alone PC databases. By being there as the PC database evolved, I was able to evolve with it. When the industry went from flat-file databases to network DBMSs, I was there. When it went from network DBMSs to client/server DBMS, I made the move. When the industry went from client/server database applications to multi-tier apps, I was there as well. And when we went from multi-tier databases to disconnected databases and XML-driven data management, I made that jump too.

Doug: Have you done much with XML?

Ken: Well, I wrote a book about it. Seriously, my second SQL Server book, The Guru's Guide to SQL Server Stored Procedures, XML, and HTML (Addison-Wesley, 2001), covered a lot of the types of work I've done with XML. I'm a big fan of it, and rarely a day goes by that I don't use it in my work in some way or another.

Doug: You currently use Microsoft SQL Server. How did you get to that database?

Ken: After I sold Cheetah and the company I had founded to market it, Software Springs, I returned to building database applications. I had been looking at client/server systems for a few years and was particularly intrigued by one called Emerald Bay, which had been designed by Wayne Ratliff, the original designer of dBase II. Unfortunately, the company that was marketing Emerald Bay ran out of money, and that software never gained much traction in the industry.

Next I took a look at Sybase, the first RDBMS to feature a cost-based optimizer, but, at the time, it ran exclusively on non-PC platforms, mostly UNIX, so I didn't do much with it. I also did some beta testing of a product called Oracle dbXL, the result of a joint venture between WordTech and Oracle. It used WordTech's dBase-clone as its front end and Oracle as the back end. Although the product itself had many problems, I could see a lot of potential in the client/server model and hoped to soon be building real apps on it.

Around this time, in the late 80s, Sybase partnered with Microsoft and Ashton-Tate to bring its SQL Server product to the PC running on OS/2. I was doing a consulting gig at the time where they were contemplating going with bigger hardware such as an AS/400 or DEC machine to host what was then considered a huge database of approximately 200GB over its lifetime. I recommended that they give this new PC-based product a chance and did a proof-of-concept project for them that had one expected result and one not-so-expected result.

The first result was that they bought into the idea of hosting their data on the PC and gave the green light to using SQL Server, then at version 1.1. That wasn't that much of a surprise to me. At least on paper, the PC-based solution would cost a fraction of anything implemented on bigger hardware. The thing that surprised me, though, was how much I enjoyed the new platform. I loved it. I instantly got the utility and elegance of the client/server model. I could see so much promise in building rich client apps that deferred to another special-purpose box to handle database work. We got started on the new project in January 1990, and I've never looked back.

Doug: What sort of work are you doing these days?

Ken: I wrote the new SQLDiag tool that is coming out in SQL Server 2005. Previous users of the PSSDiag tool will recognize it. PSSDiag was used across Microsoft's SQL Server Support organization for collecting SQL Server-related diagnostic data. It has now replaced the old SQLDiag utility and will be included in the box with SQL Server 2005.

Doug: Have you had any chance to work with the betas of Microsoft SQL Server 2005? What do you think about possibly using VB.NET or C# for stored procedures?

Ken: Yes, I've worked some with the SQL Server 2005 betas. I'm excited about the prospect of having CLR support in the database engine, but worry about the supportability of it. I shudder to think of some of the support scenarios customers may find themselves in when they begin mixing CLR code, T-SQL, COM objects, managed code, interop, and who knows what else in complex applications. Some of the problems that may arise may be nigh impossible to solve. That said, it's still an exciting addition to the SQL Server stable of features, and I welcome it.

Doug: I independently "discovered" markup languages long after Tim Berners-Lee developed HTML (http--infomesh.net/html/history/early/). My markup language involved lots of @ signs and was not terribly device independent; I hard-coded things that should not have been. Have you ever "invented" anything, only to discover that something better already exists?

Ken: That's happened to me, too! And with an HTML-like markup language I developed, no less, so I know how you feel! When this happens to me, I usually think: "It must be a fair idea if someone other than me, especially someone I respect, arrived at it independently," and "Gee, I wish I'd acted on that sooner so I could have made some money from it!"

Doug: Have you recently read any good database-related books or general programming books? Are you in the process of writing any developer-oriented books?

Ken: I'm always reading. I recently re-read Bruce Eckel's "Thinking In..." books (http--www.mindview.net/). Bruce is such a master and a pleasure to read. I also like Don Box and Jeffrey Richter, also masters in their own right. And I'm always working-either in my head or literally-on my next book. I'll have some new stuff out in the near term, though exactly what or when I can't say.

Doug: Can you think of a particularly cool tip or trick that many database developers don't know about?

Ken: With a few sp_OA calls, you can make use of many COM components within Transact-SQL. Many of these components are already installed on the typically box. For example, VBScript features a powerful Regular Expressions object, RegEx. By accessing it from T-SQL using sp_OA calls, you can write queries that feature Regular Expressions in their WHERE clauses. I explain how to do this in my latest book, The Guru's Guide to SQL Server Architecture and Internals (Addison-Wesley, 2003).

Doug: What do you do when you're not working?

Ken: I don't watch much TV, so music and books are my usual getaway. I have my CD collection ripped into my XP Media Center Edition machine, so I've been known to spend hours mellowing out to either my own collection or the vast archives of Napster and MSN Music.

Do you know someone who deserves to be a Database Geek of the Week? Or perhaps that someone is you? Send me an email at editor@simple-talk.com and include "Database Geek of the Week suggestion" in the subject line.

Douglas Reilly [source: https--www.red-gate.com/simple-talk/opinion/geek-of-the-week/geek-of-the-week-ken-henderson]

Ken Henderson: 1967 - 2008 [2008-01-31]

Ken Henderson, SQL expert and author of numerous SQL and Delphi books, passed away this past Sunday.

From NewsOK.com online edition of The Oklahoman newspaper: "HENDERSON, Kenneth W., 41, died Sunday. Services 1 p.m. Wednesday (Walker, Shawnee)."

I presume the latter refers to Walker Funeral Services in Shawnee, OK.

Thanks to Allen Bauer for sending me a link to Kalen Delaney's blog post.

I've known Ken for many years, starting with tech editing a few of his "Database Developers Guide with Delphi" books. We shared a beer at BorCon or two (or three). When I was in Dallas to speak at a Delphi Developers of Dallas mini-con, Ken took great pleasure in showing me around Dallas, his Arthur Anderson digs, and introducing me to his lovely wife and kids. Naturally, they insisted that I stay the night in their guest bedroom, and I was familiar enough with Southern/Texan hospitality to know better than to argue! We had a great time.

His role at Arthur Anderson was most intriguing to me. He was the database consultant's consultant. He was the guy that Arthur Anderson hoped would never be called. It worked something like this: AA consultants in the field get into a difficult situation - database performance not scaling with the project, usually. The front line guys would call in the experts from the AA central office. When the experts ran out of options, they called Ken.

An example: An AA client needed to receive electronic files from a large number of customers and process them within 24 hours of receipt. The individual file sizes were not enormous, but with a daily volume in the millions and rising rapidly, the system was on the verge of collapse. New files were being received faster than the system could insert them into the SQL database. What to do?

Ken spent a day listening to briefings from the AA on-site team. He took the schema and a snapshot of the system on his laptop back to his hotel room that night.

The next morning, at 9am, Ken met with the AA on-site team. "It's fixed."

The team: "You know how to fix the system?"

Ken: "It's already done. Your file backlog has been cleared. I rewrote your six month VB project in about an hour last night in Delphi. That was good for about a 100x perf improvement. Changing the SQL index to use a primary key on SSN was good for another 3 orders of magnitude improvement. And who's idea was it to dump all the received files into one DOS subdirectory!? It takes 20 minutes just to complete a DIR listing on a million files!"

Heads rolled, I'm sure, but AA got the job done and quite likely retained the client.

After hearing a few of his stories (all fully anonymized, of course), it occurred to me that Ken had an analogue in cinema: Ken was Arthur Anderson's "Victor the Cleaner" of La Femme Nikita! ("I am Victor. Victor the Cleaner.") He was doubtful when I first suggested it to him, but after renting the video and watching it himself, he just shook his head and chuckled. "I'd like to think I actually solve problems, rather than just 'erasing' them!"

After Arthur Anderson, Ken took his field experience with MS SQL server to where it was needed most - the MS SQL team at Microsoft. As a fellow remote worker (he worked from his home in Oklahoma), I frequently pinged him for advice on how to grapple with the Microsoft corp net or VPN or Redmond-centrism.

I will miss his stories, his opinions, his writing, his wisdom. Farewell, Ken.

Danny Thorpe [source: https--dannythorpe.com/2008/01/31/ken-henderson-1967-2008]