I’m on my way back from Frankfurt and PASS Europe. It’s been a long week, a quick Tue-Fri trip to the EU and my brain is a bit fried. Lots of chats and conversations, and more than a few time zones.
You re-read The Degradation of the Turing Test while I try to sleep on a plane.
We work hard at Redgate, though with a good work-life balance. One interesting observation for me (as an American) is how well most of the company in the UK works normal hours and rarely works outside of those.
However, sometimes we do find people, especially engineers, heads down and very focused. With our engineers in the office a day or two a week, they might end up coding in a group and trying to solve a challenging issue.
We used to have engineers working more than 8 hours regularly, often late, when they were in the office. I came across this page in the Book of Redgate.
The text below is: Working too hard? Why not relax with a gentle game of ping-pong.
Our offices have always had some game tables. I don’t think we have ping pong in the new office, but we have a pool table near the coffee machines and I’ll see people taking a few minutes to play a game at different times. We also (I think) still have a foosball table.
We have a piano upstairs, and some guitars in the foyer. I usually take a few minutes between meetings and strum some songs. Here’s the view I have most days when I’m in the office, a few minutes at a time.
We’re not afraid of resistant to working hard. We just try to take breaks and find balance.
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.
While wandering around the documentation looking for some Question of the Day topics, I learned something new about the money data type. This post discusses what I learned.
Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.
Did you know that you can add a currency symbol to the money data type for assignment? I didn’t. This isn’t in the documentation, but it’s something I need to submit as a PR.
In any case, I can assign money like this:
DECLARE @YenAmount MONEY; SET @YenAmount = ¥1500; SELECT @YenAmount AS RawValue;
Note that this isn’t really assigning Yen values. It’s just a number, but since the money type supports certain literals, this works. If I select the amount, I get just a number.
If I change the symbol, it still works because SQL Server doesn’t really interpret the amount and symbol or the variable name. That being said, this is bad code.
The money and smallmoney data type page lists the symbols you can use, but none of them are stored. Where this page fails is that it doesn’t help you get the values back out as the currency.
Format helps here. I can use this with some culture to determine what I want to get out. For example, I get Yen with this:
FORMAT(@YenAmount, 'c', 'ja-JP')
You can see the results here:
I can also get Pounds.
This post took me about 5 minutes to assemble as I’d already had the code, but it’s an example of a quick thing based on other work I was doing.
You can showcase this and help others see that you are learning and growing.
This month we have a very interesting invitation from Koen Verbeeck. He has hosted once before, and agreed to help me out this month by tackling another topic. We’ve shared a few beers in the EU, though not in some time, so I hopefully will get the chance to buy him a pint and thank him for this month’s invite.
He was inspired by another friend, Alexander Avidsson, who wrote about skills and the cloud, but with an interesting take. This month’s invite is about moving back on-premises from the cloud, which is something I’ve had a few customers do, or start doing. Nothing is quick when migrating systems, either to or from the cloud.
Here’s my take.
I decided on a fun title here, since so many people talk about migrating to the cloud. Is going back on-premises an un-migration? Or a re-migration? Just a migration? I won’t worry about the semantics.
I work with a lot of different customers at Redgate Software. Whether they are discussing development topics (Prompt/Toolbelt), deployment issues (Flyway), production stuff (Monitor) or compliance (all of the above + TDM), I find that most of them are still rooted in an on-premises mindset. Even when they’ve migrated to the cloud, it’s often lift-and-shift, with VMs running in AWS/Azure/GCP. In that sense, they still tend to manage things in an on-premises way.
They’re more comfortable with those skills and more confused by cloud auth systems, still. In 2026.
I think that’s still the norm and it’s easy to think that most people work in the cloud all the time. Some do, and I think most people have some familiarity with one of the major cloud systems, but I would expect that lots of people would love to come back on-premises.
Is it easy? No. It’s another migration, and while you might find it easy to re-provision hardware (whether purchased or rented from another provider like Rackspace) there are still major data movement challenges in the db world. How do I sync systems? Can I get log backups? What type of quiescing and cutover is there?
The tech stuff, matching versions, etc. is likely easy. After all, most of us don’t use the latest and greatest functions from SQL Server, so moving back to on-premises likely just works. If you are in the IaaS world, this is simple, other than the latency of copying data down (and explaining the egress charges).
I actually think customers might gain some efficiencies from moving systems with known workloads and costs back on-premises. Especially those that create lots of tickets for DBAs or developers. Any time spent moving back will come back in the skills that so many have with on-premises systems.
The one downside I think might cause some issues is HA. It’s easy in the cloud, and hard on-premises. Those are skills that some people likely need to brush up on if they don’t have a significant HA footprint with VMs.
Voice of the DBA 