Man, I am getting really bad about keeping this blog up with all of the travel as of late. Let’s see if I can’t fix that a bit. This morning I’m camped in the restaurant area of the Courtyard Westchase in Houston. While the network access in my room has been pretty good, the wireless down here completely stinks! But I have myself I nice hot cup of Coffee so I’m really in no hurry to get back to a working connection.
Most of last week was spent working with an eSymbiosis client on SQL Server 2000 scaling issues and one of their high volume Web sites. I also got wear my DevelopMentor skin at the Chicago SQL Server Magazine Roadshow event. One thing about Chicago that hasn’t changed much: those folks who go to events like this are there to learn and are prepared with great questions. Probably the highlight of that event for me – at least at a personal level – is that Janell made the trip with me despite having a fairly bad cold. She’s such a trooper!
This week I’m doing the last two of these Roadshow events. Yesterday was Houston, tomorrow is Dallas. While my Houston crowd was smaller (which was fine with me, it gave us a smaller, more casual and connected feeling I think), man were they into it! I’d really like to thank those people who came and provided me with a lot of energy to feed off of, great questions and a few laughs. I’m betting Dallas is going to knock my socks off too.
One thing that I’ve added over time to the SQLCLR part of the track is a demo of doing in-process ADO.NET programming. As you may know, I wasn’t a big fan of the switch from having in-process programming use the same classes as client side programming since there’s a good amount of design philosophy in ADO.NET that’s counter to efficient in-process programming. After looking more at how things have shaped up, I’m now much more comfortable with it since many of things I saw as potential problems just flat out aren’t allowed in in-process access like MARS and batch updates. Of course, there are reasons to do Data Access programming in-process, like calling on data stored on remote servers, working around some limitations or inefficiencies in T-SQL and so on. More on that later.