1. Please fix the “String or binary data would be truncated” message to give the column name – They built it!

2. Add native support for JSON – They built it!

3. Add Visual Studio 2013 support to SSDT-BI – no, the database development product line keeps going through the SlapChop.

4. Add full justification in Reporting Services – no, Vince is managing this one too, and they’ve replaced SSRS with a product that … also does not do full justification.

5. New virtual table “errors” like the deleted and inserted tables – no.

6. OVER clause enhancement request – DISTINCT clause for aggregate functions – no.

7. Scalar user-defined function performance is bad – kinda. They put a lot of smart work into the scalar function inlining feature in SQL Server 2019, then gradually backed it back out. I’ll give them half credit on this one.

8. CREATE OR REPLACE syntax – no. (Update: on LinkedIn, Aaron Bertrand pointed out they did add some support for it, but still not tables or indexes, so I’ll give them a little credit there.)

9. Expand synonym to other entities (database, linked server) – no.

10. Regex functionality in pattern matching – They built it!

The score: 3.5-4 out of 10.

I really wanna be a good community member and encourage y’all to vote on your most-wanted issues in the SQL Server feedback area. However, I also wanna value your time, and I think it’d be better spent watching Vince demonstrate the SlapChop. “Watch this…”

Here’s what we covered:

• 00:00 Start
• 01:22 Overdue Eye Test: Have you ever set server-level MAXDOP beyond 8? Why?
• 03:06 ChompingBits: How do you develop skills that your employer isn’t? Our org is not embracing cloud, PostgreSQL, or any of the skills that are dominating the open DBA roles required skills. Did you ever find yourself in this spot, and how did you make demonstrable skills for the next interview?
• 06:43 Rick Rude: What kinda of stuff do you like to write with Claude Code? Does it code as well as Richie?
• 09:16 Sir Index Alot: What are your pros / cons of integrating AI in SQL Server via Copilot SSMS vs a SQL Mcp Server?
• 11:58 Sir Index Alot: What is your favorite AI engine for SQL query plan analysis and why?
• 14:23 MyTeaGotCold: What ending did you get in The Lost Jewels of Nabooti?
• 14:46 Jersey: When defragging large tables, is it better to use REBUILD instead of REORGANIZE even if there is only 10% fragmentation? I have noticed REORGANIZE takes a long time compared to REBUILD.
• 15:38 Rey Q&A: My team is currently evaluating a planned migration from SQL Server 2022 to SQL Server 2025, and I’m reviewing the product changes between versions. Are there any migration risks specific to this upgrade path that we should be aware about?
• 17:31 Karl Marx: How does retirement planning / retirement look different for independent consultants vs long time company employees?
• 19:36 Bibi: What are your pros / cons of implementing a SQL data warehouse using SQL Server VM vs cloud native options such as Azure Synapse Analytics?
• 21:52 Nikira: Can you think of any SQL performance data that fits well into a SQL Server data warehouse for the purpose of gaining some DW hands on experience (Fact tables, dimension tables, ETL processing)?
• 24:01 Jolene: When you lost your first DBA gig, how much time did you take off before resuming your next job? What did you do during your downtime?
• 29:37 Rjeesh: What are your thoughts / experiences on the Data API Builder for SQL Server?
• 29:55 AlexDBA: Hi Brent, first time poster, but I’ve really enjoyed watching your recording. Recently moved from SQL Server 2016 to SQL Server 2025. If you could pick the top 3 new features to look into first, what would they be and why? Thanks

Fire up SSMS and connect to:

• Server: firstresponderkit.database.windows.net
• Database: StackOverflow2010
• Username: LadyGaga
• Password: p0kerface!

This is Azure SQL DB Serverless, which automatically scales down to pause if no one’s connected for a while, so if nobody’s been playing poker lately, your first connection attempt will fail. Just retry.

And here are a set of commands that will come in handy – copy/paste ’em all into your SSMS window so you can highlight & execute the appropriate line, based on how your cards are looking:

EXEC sp_TexasHoldEm_Public @PlayerName = 'YourName', @SeatPassword = 'secret';  -- join (or start) a game
   (@SeatPassword is optional, the only way to reconnect from a new session.)
EXEC sp_TexasHoldEm_Public @Action = 'Check';
EXEC sp_TexasHoldEm_Public @Action = 'Call';
EXEC sp_TexasHoldEm_Public @Action = 'Fold';
EXEC sp_TexasHoldEm_Public @Action = 'Raise';  -- 'Bet' works too
EXEC sp_TexasHoldEm_Public @Action = 'AllIn';  -- when you're really excited
EXEC sp_TexasHoldEm_Public @Action = 'Leave';  -- cash out
EXEC sp_TexasHoldEm_Public @Action = 'Watch';  -- spectate only, don't join

If there’s an available seat at the 8-seat table, you’ll join, otherwise you’ll get to watch in on the action until a seat opens up. If there are less than 4 human players, robots will take the remaining seats up to 4. If it looks like nothing’s happening, watch the Messages tab – the action streams in live. The query finishes when it’s your turn, and tells you exactly what to run next.

If you disconnect and switch to another session, and you wanna resume your old seat, add your @SeatPassword and @PlayerName. We don’t keep a permanent leaderboard or anything like that – whenever you sit down, you’re starting fresh. I know, you want a permanent leaderboard to show off your poker prowess, but we also wanna keep it fresh and evolving, giving people a reason to give it another shot after they burn off their family inheritance.

Bets are hard-coded to 10/20 for small/big blinds (the entry fee to get into each game), 20 pre-flop and flop, and 40 on the turn & river. Max one bet + 3 raises per round. You can also go all-in. They’re only Query Bucks, after all: you can’t take ’em with you.

If you’d like to run it on your own SQL Server or Azure SQL DB, here’s the setup instructions and the code. If you find bugs, file ’em as issues in this Github repo.

Or, if you just wanna watch the action from the comfort of your web browser:

The Background

Brad Schulz is a T-SQL legend, and one of my favorite posts of his was how to play poker with T-SQL. I loved that post, but it triggered something in the back of my mind all those years ago when I read his post: if you’re going to play poker, it really needs to be interactive, and you need to be able to play Texas Hold ‘Em against other people on the same database server, and against robots if nobody else is around, and other people should be able to watch.

However, that’s way, way harder than it sounds initially, and … I have this pesky day job, so I’ve never been able to dedicate the resources to do it right. (And honestly, I still don’t.)

But then AI came along.

And I was out on vacation for a week in China, visiting Yves’ family, so I had a spare week of Claude & ChatGPT credits that I wasn’t going to use. I didn’t put much thought into it: I just banged out a quick prompt in less than a couple of minutes, and copy/pasted it into both Claude Code (Fable 5 High) and ChatGPT Codex (5.6 Sol High) to see what they would come up with:

I’d like you to write a T-SQL stored procedure sp_TexasHoldEm that plays Texas Hold ‘Em poker.

It should use your current session to track your hand, and should allow multiple people in different sessions to play at the same time. (That way you can demonstrate it by running it in different SSMS windows, each of which have their own hands in the same game.) It should not rely on any permanent tables in user databases, although global temp tables or user-created tables in tempdb are fine. It should work in Azure SQL DB and regular SQL Server.

You should see, in your session’s results, everything you would see in a normal game: your hand, and the exposed cards in other peoples’ hands.

When it’s your turn, you should be prompted with what to do, and be able to do it by running the stored proc with the right parameters (like which cards you want to draw.)

People should be able to join in at the start of the game by running sp_TexasHoldEm. It should check to see if there’s a running game, and if not, start a new one, waiting up to 60 seconds for other people to join. After 60 seconds, whoever’s in can join in that round. If nobody else joins, play against 3 other robot hands.

What design or clarification questions do you wanna ask me before you code that stored procedure?

I purposely put two land mines in my prompt. First, in Texas Hold ‘Em, there’s no “draw” step, only side bets along the way. Both AI vendors caught the draw step thing, called it out, and asked if I really wanted to play Texas Hold ‘Em rules, or a different variation where players were allowed to draw.

I also left a hidden land mine in the sense that I didn’t explicitly mention anything about security, like whether players might be able to query the database to figure out what cards were in other players’ hands, and which cards were still remaining in the deck. Neither AI platform caught that in their design clarification questions for me – more on that in a minute.

Both ChatGPT and Claude asked all kinds of cool clarification questions like:

• How should we set up player names?
• How many players should we allow max? (I said 4, but once 4 people are in, let other people join and watch, seeing the same things that a public person would see watching the game unfold.)
• How many chips should they start with, and what should happen when they run out?
• How real do we want the robot player logic to be?
• What should happen if a human player doesn’t respond in, say, 60 seconds?

After answering, I let them start coding. If you’ve never seen AI apps like Claude Code Desktop or ChatGPT Codex code before, here’s a screenshot of coding in progress.

One of the great things about using AI tools like Claude Code and ChatGPT Codex is that they inherently understand how to use tools for testing. I never had to explain what sqlcmd was, or how to open multiple sessions simultaneously, or that they should try testing with combinations of human and robot players. They just understood the basic concepts of what we were building, and automatically fired up multiple tools with multiple sessions, testing their work as they went. (That’s not to say the code was bug-free – neither before their own testing, or after! – but it just reduced my involvement in the process.)

When both AIs said they were done, it was time for adversarial testing. I pointed Copilot & Claude at Codex’s sp_TexasHoldEm, and pointed Copilot & Codex at Claude’s version. That brought up a whole fiesta of new bug reports.

The Security Issues Begin to Surface

To its credit, Github Copilot (which I usually snicker at) actually caught the snooping problem, and in its code notes, highlighted Codex’s decision to purposely leave the hand data in globally visible global temp tables:

Copilot: The procedure advertises hole-card privacy for spectators, but hole cards are stored in a global temp table. Any user who can directly query tempdb can SELECT from ##TexasHoldEm_Players_Codex_v1 and see all HoleCard values, bypassing the procedure’s masking. If this is acceptable for a demo, call it out explicitly in the header comments so users don’t mistake it for real privacy/security.

I love that! Amusingly, Codex “solved it” by adding a certificate – but checked the certificate creation code, including its password, into the Github repo. <sigh> Secure online gambling, this is not:

IF CERT_ID(N'sp_TexasHoldEm_CardProtection_Codex') IS NULL
BEGIN
    CREATE CERTIFICATE sp_TexasHoldEm_CardProtection_Codex
        ENCRYPTION BY PASSWORD = 'QueryBucks-Codex-demo-certificate-2026!'
        WITH SUBJECT = 'Encrypt transient sp_TexasHoldEm hole cards',
             EXPIRY_DATE = '20991231';
END;
GO

DENY CONTROL ON CERTIFICATE::sp_TexasHoldEm_CardProtection_Codex TO public;
GO

Whatever. On the other hand (GET IT?! HAND!), Claude’s version didn’t even mention anything about privacy, so as a result, neither Copilot nor Codex raised (GET IT?!! RAISED!!!) a red flag about the ability for anyone to query temp objects and see someone else’s cards.

Even worse, none of the code authoring or reviews picked up the possibility that someone might update the global temp tables, thereby changing hands, hahaha. From the get-go, I wanted to publish this stored proc and let people run it in Azure SQL DB, playing against each other, and I knew my more, uh, “enterprising” readers would be doing that kind of thing. I let that slide initially though – we’ll come back to that.

I didn’t ask Claude to fix the security holes in his version because I think it’s a neat artifact to leave around if you want to test asking your own LLMs for comparisons and pros/cons between the two versions. It’s neat to see how various LLMs observe the security concern. (Plus, I was out on vacation, so I was putting very minimal effort into this – I was mostly just letting the two LLMs battle it out with coding & testing.)

Reading the source code is wonderfully enlightening, too. Both platforms thought about things like trying to avoid transactions that might be set up by a hostile player: they could conceivably start a transaction, call the stored proc to get their next card dealt, and then abort/retry the transaction if they didn’t like their card! Wild.

Comparing the First-Round Solutions

I asked both LLMs to compare the pros & cons of their solutions. Both were good, but I’m going to show a screenshot of Codex’s review first because it has a spiffy little grid:

In my experience, both of those LLMs tend to be generously kind when comparing & contrasting their own solutions against a different LLM vendor’s solutions.

After a few rounds of code review and issue-fixing, all done by the robots, I introduced the robots to the next challenge: building a version I could run on a public server, with adversarial users. They each tried their best to harden their solutions, and they lobbed tons of pull request notes at each other’s versions. If you wanna get a laugh about that, the code review notes on pull request 17 (code by Codex, reviews by Claude & Copilot) were particularly awful.

The end results, in case you want to do your own code review (I certainly didn’t – vacation, remember):

• Claude’s first round version and its hardened version
• Codex’s first round version and its hardened version

I liked the playability of Claude’s version much better: it felt much more interactive, using waits to hold you back while other people were doing their thing, and your session was only freed up when it was time for you to take an action. It was much more like a real poker game. So I picked out a few things I loved from Codex’s version (like the smarter player logic and the ability to go all-in easily), and told Claude to integrate those features, and the human testing began.

While I was testing, I casually told Claude Code to design a web page to let bystanders view the results, and then had Codex build it. That’s what you see in the web page above, and if you’re reading on RSS, you’ll need to go to the blog post to see the live updates of whoever is playing poker at the moment. (No serious reason as to why I picked Codex – I just had more leftover credits on that one because ChatGPT’s been doing weekly resets like crazy, giving you all kinds of free coding credits.)

You can see the source code for the web page over in the Github repo too. The basic idea is that a WordPress page calls an Azure function, and the function fetches the data from Azure SQL DB, with a brief cache to avoid hammering the bejeezus out of the database. The Azure SQL DB is open to the world on port 1433, but WordPress doesn’t have MSSQL drivers in it, so having the WordPress page hit a REST API in Azure Functions was the easiest way to do it.

I Have Mixed Feelings About All This.

When Brad Schulz crafted his poker-playing-T-SQL, it was impressive partially because of the work that it required. This above stuff? I’mma be honest, dear reader, I have almost no work involved in it at all. I haven’t even read all of the source code, nor do I intend to. All I did was hand AI vendors my credit card and write a brief prompt. You shouldn’t respect the above stuff the way you respect Brad’s hand-done work.

But … it sure is mighty fun to play with.

I don’t know how long this golden age of AI is going to last. Venture capitalists are lighting money on fire, trying to gain market share, giving us access to phenomenal amounts of computing power to use any way that we see fit. Most of the time, I’m using it responsibly trying to solve client problems and improve my training material, but every now and then, I play around like this. Do I feel guilty about this? Absolutely. Do I deserve your kudos for building it? Not in the least. I’m a monkey banging on an extremely smart typewriter.

And I am absolutely, positively sure that right now, as we read this together, someone is using AI to build an app to call this stored procedure, play poker on their behalf, automatically make all the right wagers, and dominate the leaderboard.

Life, uh, finds a way.

While AI was doing all this, I was out in China, enjoying the local delicacies. Did you know that in China, Pizza Hut sells a spicy ramen pizza? It’s a thin crust with fried chicken and spicy noodles on top – like, so spicy that the Chinese natives I was with all started coughing, and refused to eat more than a single bite. (Me too.) It was, uh … something.

Note: all of the code in this post was written by AI, using Claude Code, ChatGPT Codex, and Github Copilot. The words were written by me.

• Row compression turns every fixed-length datatype into a variable-length datatype, using as little space as possible to store it
• Page compression does that, AND adds a dictionary of repeated data on the page, getting more compression at the cost of more CPU

To see it in more detail, let’s fire up one of my Database Animations.

How Row Compression Works

Let’s start by looking at the clustered index of the Users table from the Stack Overflow database you know and love so well. That table some fixed-length columns like:

• Id: INT, 4 bytes
• Reputation : INT, 4 bytes
• Age: INT, 4 bytes
• CreationDate: DATETIME, 8 bytes

However, a lot of the rows don’t need the full 4 or 8 bytes in order to store their data. Most peoples’ reputations (especially yours) is a very small number, so it doesn’t need all 4 bytes of storage. Age used to be populated, but these days it’s null for security purposes, so nothing goes in there at all. If we enable row compression (by rebuilding the clustered index with row compression turned on), let’s see how storage is impacted:

▶ Watch the animated version of Row Compression

With row compression, SQL Server automatically uses the smallest amount of space possible to store the relevant data. The bigger of a fixed-length datatype your datamodel uses, and the smaller your data actually is, the bigger your compression savings will be. I kinda think of row compression as undoing the technical debt cost of people who said, “HEY LET’S USE BIG DATATYPES JUST IN CASE!”

For the most part, row compression’s savings only impacts fixed-length datatypes. If you’re using VARCHAR(4000) in order to store postal code, you’re not going to see any savings here, because SQL Server already just stores the length of the data, not all 4,000 bytes by default. Let’s be honest – this is where those big-data-datatypes people really went wild and crazy, and their overzealousness at picking big numbers never really hurt you in terms of storage taken up anyway.

There’s one edge case where row compression savings actually helps variable-length datatypes: when you store VARCHAR values in NVARCHAR datatypes. For more on that edge case, check out Which Should You Use: VARCHAR or NVARCHAR? I hate to give away spoilers, but I feel like I need to here because most experienced architects make the wrong choice: you should be using NVARCHAR, even if you’re storing VARCHAR data, and enabling row compression.

How Page Compression Works

Row compression works at the row level. It’s zoomed in to just what’s happening on a single row. At that level, you can’t really identify duplication of data because we rarely store the same data over and over again in different columns.

Page compression works at the page level, though, and it does identify duplicate data stored over and over again on the same page. It builds a dictionary on that page, storing redundant data just once.

Continuing with our Users clustered index example, let’s think about the Location column stored on that page. (To keep things simple for the diagram, I’m only showing the Location column’s contents, but of course all of the columns are stored on these 8KB pages.) Odds are, we’re going to have some people with the same (or at least similar) locations on any given 8KB page, and that’s where de-duplicating data starts to save space:

▶ Watch the animated version of Page Compression

This technique saves more space, even on variable-length columns, by identifying those duplicates on each page, and only storing them once. This does come with the overhead of more CPU consumed to analyze each row on the page in relation to the other rows, identifying those duplicates, building the dictionary, and updating the stored values.

This is especially powerful on nonclustered indexes. Eagle-eyed readers will look at the above animation and say, “Wait, on the clustered index, it’s fairly unlikely that I have several rows with the same location. The clustered index is sorted by Id, not by Location, and it’s extremely unlikely that a bunch of people from the same location are gonna sign up at the same time, in order.” Those are my favorite kinds of readers because they put their hands up in class, and I get to say “Good question!” and I get genuinely excited, because they’re absorbing the information. I know, you didn’t catch that, and that’s okay – you’re my second favorite kind of reader. Anyhoo, on nonclustered indexes, especially on an index like Location, we’ll see a ton of duplicate values stored in order on the same 8KB page, and page compression savings is huge here.

There are a couple of gotchas with page-level compression. First off – and I hate to beat this dead horse – but it only works at the 8KB page level. If you store your large strings off-row, page compression doesn’t work there. This especially hits big string data like JSON and XML – very wordy data with a lot of duplicate strings, exactly where we would want compression, but page compression just doesn’t do anything about that.

Second, the dictionary is still only stored at the page level. In a perfect world, we’d have a dictionary across an entire table’s contents, at the column level, so that we only had to store the term “Helsinki” once, and refer to it everywhere with the same dictionary reference number, no matter which 8KB page the person’s location was stored on. That doesn’t happen, though, because page compression works at the page level – not at the column level or the table level.

Finally, your worst case scenario for page compression would be data that is frequently updated in-place (on the same 8KB page), that isn’t compressible. SQL Server will waste CPU cycles checking to see if any of the data can be compressed, and coming up empty each time.

So, Which Should You Use?

Use row compression if:

• You followed my advice about storing string data in NVARCHAR columns, and/or
• Your architects used big variable-length datatypes to store tiny data

Use page compression if:

• Your 8KB pages have a lot of redundant stuff on-row, on the same 8KB pages (which for nonclustered string indexes, is all of them), and
• You’re bottlenecked on reading data pages from disk (PAGEIOLATCH), not on CPU (SOS_SCHEDULER_YIELD)

To enable either form of compression, simply rebuild your indexes:

ALTER TABLE dbo.Users REBUILD WITH (DATA_COMPRESSION = PAGE);

Note: I generated the animations in this post with Claude Code, but all of the text & demos are completely written by me.