Presenting Getting Started with SQL Server Compact Edition 3.5 at BUG.NET Meeting

Just wanted to let everyone know I’ll be doing a presentation this coming Tuesday night, August the 12th for the Birmingham .Net Users Group (BUG.NET). My topic, as you may have guessed from the title, will be using SQL Server Compact Edition.

While I will be using Visual Studio 2008, I will point out which pieces are 2005 compatible. I will also cover the use of both traditional coding techniques as well as how to use LinqToSQL to talk to the Compact Edition.

The meeting takes place at 6:30 pm at New Horizons Training Center in Homewood.

I also plan a new series of blog posts to start later this week on the subject, and will be creating a new Code Gallery site to hold my examples.

Also, don’t forget the regular BSDA meeting this coming Thursday night, the 14th. Also starting at 6:30 pm at New Horizons, Shannon Brooks-Hamilton, a software usability expert, will be there to talk about user interface design. Lots of good thought material on how we can make better UIs for our users.

Arcane Review: Expert SQL Server 2005 Integration Services

If you recall my “Good Reads” post from June 25th, you will remember I am a big believer in books as a learning medium. I like to employ a lot of different ways to learn: user groups, blogs, podcasts, videocasts, and magazines to name a few. But for really in depth coverage, it’s hard to beat a nice book in your hands. I got some good feedback from my mention last week of Andy Leonard’s new e-book on Data Dude, so I thought that I would continue by adding book reviews to the blog every so often.

Expert SQL Server 2005 Integration Services For this review I thought I’d cover a book that seems to constantly be on my desk lately: Expert SQL Server 2005 Integration Services, by Brian Knight and Eric Veerman. This book does a really good job and is specifically targeted toward the data warehousing professional. One entire chapter is devoted to ETL for dimension tables; another chapter focuses on the fact tables. It was great to have coverage so focused on these topics.

Another favorite part of the book is the two chapters on deploying and managing SSIS packages. So often these topics are glossed over, especially the managing piece. The book does a great job in covering all the tools and practices around this subject. I’ll mention one more chapter, one that focuses on package reliability. They cover logging, auditing, event handling, checkpoint files, and even suggestions on testing error handling logic.

There are many more chapters in the book, such as migration from DTS (SQL Server 2000) and Scalability, for you to discover. The other thing I love about this book is the brevity. The authors cover an amazing amount of information in just 382 pages. As a busy, busy person I very much appreciate the conciseness they achieved without sacrificing any clarity.

I’ve met both authors, and have heard them speak. They are both very nice, knowledgeable individuals, and I highly encourage you to attend one of their presentations if you get the chance, or if not at least buy their book from your favorite retailer; you will find it a great investment.

Deep Fried Debugging

I was listening to the current episode of Deep Fried Bytes and was reminded of an important lesson. In case you haven’t heard of it, Deep Fried Bytes is a relatively new but very good development podcast. I highly recommend the podcast, it’s become a favorite on my Zune.

The hosts, Keith and Woody were interviewing members of the Microsoft.com support team. Yes, the guys who keep the actual Microsoft.com website up and running. Keith Woody asked them about a really challenging problem they hand, and one of the team recounted the tale of a site that had been in production about a year, when performance suddenly tanked. Naturally they went through the standard debugging questions, including “has anything changed in the code?” Since nothing had, they said “oh, well can’t possibly be the code” and went on to look at other things.

They went on to look at other things before finally, in desperation, coming back to the code. It turned out there was a scalability bug that had been there since day one, buried deep in a stored procedure. The select statement inside the stored proc caused a table scan. Not so bad when there were few records but after being up for a year the number of records was bogging down the stored proc.

I have been on many projects where a developer insisted the bug couldn’t possibly be in the code as it’s been running “perfect” and no recent changes have been made. The lesson to learn is never to rule out anything when looking for bugs. True, you should start with the most likely suspects, if no changes have been made to code then the probabilities of it being code are low as compared to say a hardware issue, but don’t rule it out completely. Get the entire team working in parallel. Let the developers look at the code, the DBAs at the database, admins at the server and network, and so on. Through teamwork, and being open to all possibilities you can achieve some deep fried debugging.