Triggers can be really useful in your database but you have to be careful with them. We often use them to record history to a separate table (at least, until we can implement temporal tables) or keep track of when a record was last updated. It’s usually implemented via an AFTER UPDATE trigger.

Several times a day, I’m alerted by our monitoring suite that two processes were deadlocked. This is a (mostly) normal event, but one that we’d like to avoid if we can. More than a few times, I observed this pattern:

This week I had a user come to me asking about how fields were defined on a few tables he was using in writing some reports. Long story short, he’s been tasked with writing some new reports and updating existing ones, but he doesn’t have visibility to the database itself so he’s left with the “ok, let’s try this” approach and then reading error messages to debug when things go sideways. Very tedious.

Every year, I spend the Sunday after SQL Saturday Rochester scanning & processing raffle tickets for our wonderful sponsors. Here’s how the system works:

• Attendees get tickets (one ticket per sponsor) with their name, the sponsors name, and a QR code on them
• The QR codes represents a URI, unique to the combination of event, attendee and sponsor.
• Attendees drop their tickets in a box to enter the sponsor’s raffle prize drawing
• When the URI from the QR code is accessed, it registers in the SQL Saturday system
• Organizers run a report for each sponsor that includes the contact info of all attendees who dropped off a raffle ticket, then email the report to the sponsor

It works pretty well, but the hangup is that most QR scanners will open your web browser (or prompt you to open it) to the URL on each scan. For 150+ tickets, this takes a long time. Every year, I lament “oh, how I wish I could just scan these, collect the URLs into a nicely formatted file, and script this whole thing”.

A couple weeks ago Carlos L. Cachon (blog|twitter) put out a call on Twitter looking for SQL Saturday organizers to join him on the SQL Data Partners Podcast. When I signed on to record, I learned that Chris Hyde (blog|twitter) and Eugene Meindinger (blog|twitter) were joining us. I’ve met and spoken with all three previously, so it was easy talking to everyone and I thought the conversation flowed well.

Check out SQL Data Partners Podcast Episode 126: SQLSaturday Edition.

This month’s T-SQL Tuesday from Aaron Bertrand gives us a choice:

• Life beyond the technical in a search for what Drew with the Burdensome Name calls #sqlibrium
• Your own T-SQL bad habits

And I’ve got one, maybe two posts in progress on the first topic. Alas,

ironic that being swamped with work is blocking me from writing my #sqlibrium #TSQL2sday post

• Tweet by me at Mon Feb 12 21:30:53 +0000 2018

Thanks to Eugene Meidinger (blog|twitter) for nudging me in the direction of posting this. Ever since this month’s T-SQL Tuesday was announced, work and non-work has been a complete whirlwind and I have failed miserably at reaching sqlibrium.

I need a new social media profile picture.

That’s one of the most important (non-technical) conclusions I drew from my week at PASS Summit 2017. It seemed like everywhere I went, I heard “I didn’t recognize you without the hat!” The picture I use on Slack, Twitter and Instagram is the same one I use here on my About Me page. This photo was taken in 2014 at the West Bend, WI Cache Bash and it’s one of the few photos of myself that I actually like (harsh shadows aside). I nearly did bring The Hat with me, but decided against it as it’s big, heavy, and not really an “indoor” hat.

I wrote a post over on the dbatools website about how to get involved with improving comment-based help

Working on the CBH is a great way to get started with the dbatools project, even (especially) if you’re not a PowerShell expert or MVP-level DBA. Getting everything clean and consistent in the CBH is an important step on the road to 1.0. Along the way, you’ll pick up on how dbatools is put together, discover functions that you can use in your day-to-day work, and get a feel for PowerShell best practices. You will learn from this experience!

In the course of testing a major upgrade, one of my users in Accounting happened upon a problem with one of her scenarios. The web app we were working on had a habit of “locking up” on people when loading some pages; in most cases, it was because the server was pushing a huge HTML table to the client, and most web browsers struggle when faced with several megabytes of markup and thousands of rows in a single table. Digging into the source code for the page and SQL Profiler (yes, I know Extended Events are a thing), we were able to isolate the query.

I am very happy to announce that SQL Saturday returns to Rochester, NY on March 24, 2018. This is the Flour/Flower City’s seventh SQL Saturday and SQL Saturday #723 overall. This is a little earlier than in years past due to the scheduling of other SQL Saturdays as well as the availability of our venue and key people, and I can’t wait to see how this change works out.

SQL Saturday is a free one-day event for anyone working with the Microsoft data platform. Whether you’re a DBA, developer, work in PowerBI, work with people who spend their day with data, on-premises or in the cloud, or are just curious about it, this is the event for you.

This tweet showed up in the dbatools Slack channel Friday afternoon.

My first thought was “huh? John (twitter) hadn’t kicked code in previously? I thought he had.” Once I was over that, I reflected a bit on what John wrote here, and was reminded of how I felt when I started helping out with dbatools.

It’s similar to Impostor Syndrome - I felt like I wasn’t doing much, small things here and there, in large part “just” documentation cleanup. The feeling that I was just throwing changes into the codebase just for the sake of making changes. It took me a couple of months and talking to several people before I understood that what I was doing was useful to someone other than myself and internalized what I was hearing.