Voice of the DBA

Tag: syndicated

  • A Last Minute Trip to the EU

    My life has some crazy travel stretches for sure. Between speaking, office visits, customer trips, I can be on the road a lot. As it is, I’ve flown across the Atlantic six times this year, and now I’m coming back from a 7th.

    I wasn’t planning on this trip. However, life doesn’t always go as planned and we have to roll with the changes.

    My daughter is heading to Lueven University (KU Leuven) for graduate school. My wife and one of my sons planned to take her and help her get her apartment, bank, etc. set up for school and do a little tourist time. Her other brother decided to go as well, with the plan to leave on 10 Sept and come back the next week.

    I was left out because I have to be in San Diego on Mon, 14 Sept. I have had too many 50 hour trips to other countries, so I was going to stay home.

    However, my wife got injured from a horse and can’t fly. She’s OK, just uncomfortable and flying isn’t an option. We were planning on using her status to take extra clothes, better seats, etc. Without that status, it’s a very expensive trip (or an uncomfortable one). Since we had an award ticket, moving me into her slot (with the same status) works. It also gives the kids someone to lean on.

    So I flew Thur to Brussels, helped get things set, and I’m back home today, making my way to San Diego. The kids were going to Paris today, so they won’t miss me.

    Life in the EU is rough, isn’t it?

    In any case, republished editorial, vacation day taken, and it’s going to be a long day today.

    If you can avoid it, I recommend against 4 days trips to Europe from the US (or the reverse).

  • The Book of Redgate: Hours

    I have said and written this many times: Redgate Software is the type of company I’d want to build if I founded another company. It’s a great place, and one of the things I appreciate is that we value outcomes.

    One of our values is:

    2026-06_0204.

    The text on the next page continues the sentence:

    What you achieve is more important than how long it takes.

    Building software is challenging, and building software that can be sold is difficult. We’ve had lots of successes and some not-successes. However, we work towards building the software and celebrate the achievements.

    However.

    If you’ve built software, you know it usually takes longer than expected and people want it sooner. Many teams know me as the “do it faster” guy. I know software takes time, but I also know that in the business of selling software, we need focus on things that are useful and valued by customers.

    I don’t complain that it takes too long to build everything, but I do press on the focus to get the important things done first, which aren’t always the fun or easy things.

    Ultimately we as a company appreciate when we have something done and working for customers. We don’t go back and lessen the importance of the effort because of the time it took. We do look to see if we can do better in the future, which is something I’d hope most software engineers would do.

    I have a copy of the Book of Redgate from 2010. This was a book we produced internally about the company after 10 years in existence. At that time, I’d been there for about 3 years, and it was interesting to learn a some things about the company. This series of posts looks back at the Book of Redgate 15 years later.

  • PostgreSQL Support in the Data API Builder

    Next week I’m at VS Live in San Diego (register and join me) and one of my talks is on the Data API Builder. I want to show how this gives you REST, GRAPHQL, and MCP access. As a part of the talk, I also wanted to show this working across platforms, so I’m showing this in PostgreSQL as well.

    I’ve been experimenting this in a few ways, but I decided to see how hard it was to add PostgreSQL support. I decided to follow a similar structure as my SQL Server demos, which are all in my GitHub repo.

    First, I added a .env file, which has the credentials. THIS IS A DEVELOPMENT structure, and not something you’d deploy from a repo. Secure your production stuff! This is my local file (in .gitignore), but it’s a simple connection string.

    2026-08_0375

    Next, I copied (well, I guided Claude to do this)  my demo01.cmd and edited it to say the type is “postgresql” instead of SQL Server. The new file went into a separate folder as (demo01.cmd)

    2026-08_0375

    I had it copy the demo02.cmd and alter this for the PostgreSQL Pagila sample db, which is installed and running on my machine.

    2026-08_0376

    Note, this errored out at first, with the note that DAB doesn’t support the PostgreSQL array type. I ended up having Claude create a view that skips this column and the column that is a vector type. Hopefully those will be supported soon by DAB.

    2026-08_0373

    Next, dab start, and I had a running API server over my PostgreSQL database in just a few minutes. Here’s my Bruno query of the GraphQL endpoint for Pagila.

    2026-08_0377

    Not enough people are using or trying the Data API Builder. This is truly an easy way to get a usable API over your database without a lot of data access layer work for developers.

  • T-SQL Tuesday #202: 100 Hours

    It’s time for T-SQL Tuesday again and this is a great prompt to start writing. I might have written about this before, but it’s a story that sticks with me. It’s a memorable one, and it was quite the outage, one that lasted for weeks.

    Thanks to Marlon for this invite on unforgettable outages..

    T-SQL Tuesday is the monthly blog party, and if you want to participate, feel free to write on a blog, Linked In, or anywhere else and link your post to the invite. If you’d like to host, ping me. You need to write an invite and a recap. I’m always looking for people to host, so jump in and join the party.

    New Year’s Eve

    I was a relatively new hire, a former intern, at a large electrical utility in Virginia. I worked as a network admin at a nuclear power plant in Surrey, VA. I showed up at work on New Year’s Eve at 5:00pm. We were planning on deploying a new database server running SQL Server, along with a new application to track radiation exposure for workers. This was a mandated change to our tracking, which needed to go live at midnight. I was supposed to be a bystander, helping developers from our internal group implement the server and then take over administration for the future.

    New hardware had arrived, and we had installed OS/2 1.3 already. This was the “hot” new OS to us and to the plant, which would run SQL Server 4.2, a real database. Instead of the previous BTrieve database on our Novell network. The developers installed SQL Server, showed us how to add logins and users, and we verified this was running. The devs then went into the plant (with escorts) to install their software on various machines with radiation badge readers. These machines were the “clients” that connected to the new database server to look up user names, verify their total exposure, and record new exposures.

    We finished installations well before midnight and then went to eat some food. At midnight, we turned the old system off, and the new one went live. This was accomplished by stopping one application on the client machines and running a new one. A nuclear plant is busy, with people constantly moving in and out of spaces where they could be exposed outside the reactor. We saw workers getting badges, logging the device to their account and then entering the plant. Quick and easy.

    After 30 minutes or so, some workers would return from the plant, run the app, log in and have their badge scanned, recording their exposure. Many were 0 rads, but a few might have picked up minor exposure.

    Then the crash. Once we started getting a little busy, with 5 or so people logging in the application stopped responding. I worked with the devs in the server room, where we saw the new OS/2 server hung. We rebooted it, thinking something went wrong.

    This happened again.

    And again, and again.

    We ended up seeing either the entire server hung, or SQL Server not accepting connections. In the v4.2 version, we didn’t have a Dedicated Administrator Connection, when the server was hung, we could only see external, OS-level counters. Our network staff (4 of us) stayed until around 4am, at which point my boss sent a few people home. They had families, so he and I remained behind. We alternately caught naps and were on call to reboot the server. Sometime during the morning the plant rolled most people back to paper, manually tracking workers and exposure on cards, one per worker. We kept one machine on to keep testing. That worked, but when a second client was added, the server kept hanging.

    My boss and I stayed, trying all our tricks, reading lots of OS/2 and SQL Server  docs, and trying to help developers figure things out. The plant wasn’t that busy on Jan 1, but busy enough that their system kept freezing up. Lots of arguments amongst our staff, our managers, and the software development group. I stayed overnight, rebooting servers, napping in the server room (a cold room) with a hat and coat. When the “normal” day started on Jan 2 and coworkers showed up, I went home.

    I returned late afternoon to relieve the other staff, working through the night again, mostly rebooting a server and trying to find a cause. I learned about the “probe” user, which was a backdoor account used for accessing data. I never found a reason why the application didn’t work as expected, other than the developers didn’t really test with multiple clients.

    In any case, it didn’t matter. I worked 100 hours that week, from Dec 31-Jan  6. Since I was being paid hourly, I was happy to do so. My partner, less happy.  I continued working over 80 hours every week that month. The developers stabilized things enough for the system to be used, but it still was rebooted every few hours. Since the plant runs 24×7, that meant the 5 or 6 of us needed to ensure someone was there all night long.

    A profitable month (and the next), but a hard one.And an unforgettable outage.