« first day (5162 days earlier)   

00:06
that is pretty slick
it's a bit strange that you can only use g3 from twitter, and not from the grok website
at least as of yesterday afternoon
still the case
00:22
Yeah I suppose it's either because it's still quite new or because it's free for the moment
Promo
It all makes sense
Even if it’s annoying at the moment
Tomorrow is a dark day for SQL Server for the third time
00:41
Is it
01:02
Why's that then
I am not at liberty to say
Don’t wanna get anyone sacked
I see
And which were the two prior dark days would you say
Or are you not at liberty
Perhaps you lack freedom
01:18
It would be inappropriate to comment further at this juncture to respect the sanctity of various arrangements
01:58
> Two events in Microsoft SQL Server history that could be considered "dark days" are:

1. SQL Slammer Worm (2003) – This was a devastating worm that exploited a vulnerability in Microsoft SQL Server 2000. It spread rapidly, bringing down major parts of the internet within minutes. Many organizations suffered from network outages, including airlines, banks, and emergency services. The vulnerability had been patched six months prior, but many systems remained unpatched, highlighting security complacency.
(from Chat GPT)
> Absolutely! Here’s a more sarcastic take on the original two:

SQL Slammer Worm (2003) – The Weekend Destroyer
Ah, the early 2000s—when ignoring security patches was basically a company tradition. Enter SQL Slammer, the tiny but mighty 376-byte worm that showed just how much damage could be done when people ignored Microsoft’s warnings. In under 10 minutes, it brought the internet to its knees, crippling banks, airlines, and even emergency services. The best part? Microsoft had already released a patch six months earlier, but who has time for updates, right?
2
I told it to redo those in a more sarcastic style. That was fun
@ErikReasonableRatesDarling Indeed a sad occasion
02:22
@SeanGallardy we’ll never bounce back from this. don’t have the elasticity.
@ErikReasonableRatesDarling Not yet, but give it a few days, you might find yourself with some new found stretchiness.
Wordle 1,343 3/6*

🟨⬛⬛⬛⬛
🟩🟨🟨🟨⬛
🟩🟩🟩🟩🟩
I’ll be searching for it
 
2 hours later…
04:04
@PaulWhite never saw this before, but interesting. command.Prepare();
 
1 hour later…
05:12
@HannahVernon Yes, it's what I was talking about at sql.kiwi/2025/02/sniffing-prepare-prepexec/#benefits
 
7 hours later…
11:47
@HannahVernon FYI it currently doesn't actually do anything. It just does some internal bookkeeping on the command and parameter objects.
Code is here and here
It does mean that it goes via sp_prepexec once you actually call the reader function, but doesn't do anything at the point you prepare. See the notes here
Wordle 1,343 4/6*

⬛⬛⬛⬛⬛
🟩⬛🟩⬛🟩
🟩🟩🟩⬛🟩
🟩🟩🟩🟩🟩
 
2 hours later…
13:52
@Charlieface cheers
14:22
Wordle 1,343 4/6*

⬛⬛⬛🟩🟩
⬛⬛🟩🟩🟩
⬛⬛🟩🟩🟩
🟩🟩🟩🟩🟩
hello everyone i hope you are preparing for or currently in the midst of having a great weekend
Wordle 1,343 5/6*

⬜⬜🟨🟨⬜
⬜🟩🟩⬜🟩
⬜🟩🟩⬜🟩
🟩🟩🟩⬜🟩
🟩🟩🟩🟩🟩
14:50
Wordle 1,343 4/6*

⬜⬜⬜⬜⬜
⬜🟩🟩⬜🟩
⬜🟩🟩⬜🟩
🟩🟩🟩🟩🟩
these are not frogs
why do you not bring me frogs for friday
 
2 hours later…
16:36
Frogs for the frog lord
17:17
> Table spool la apelul unui UDF
17:27
do you smell burnt toast?
no your mom left a while ago
hey, @ErikReasonableRatesDarling, quick follow-up to a chat we had a few days ago, about your video showing how to use sys.dm_exec_input_buffer to log the actual SQL statement that fired a trigger
It works great, but in practice the queries being captured for application activity look like this:
(@P1 VARCHAR(50), @P2 INT)
UPDATE "dbo.mytable"
SET "Tag-Number"=@P1
WHERE "ID" = @P2
so no actual parameter values being shown (and the "parameter" column returned by sys.dm_exec_input_buffer is just 0)
This old SO question seems to say there is no way to get those param values:
1
Q: SQL Server dm_exec_input_buffer Problem with linq dynamic query

Hamidreza FatolahiI'm logging my SQL Server 2017 stored procedure parameters. I use this code: select event_info from sys.dm_exec_input_buffer(@@spid, current_request_id()) Inside my procedure to list parameters and everything is ok (I can see my parameters and values that are passed to). The problem is when a...

So I'm left with parsing the DELETED and INSERTED tables, which is cumbersome but possible
Does that sound right? Anything I'm missing?
yes but you're better off missing it
17:43
lol ok. but I'm not misunderstanding dm_exec_input_buffer or getting bad info from that link. Answer was from "David Browne - Microsoft" after all
he is correct in this case
Ok thanks
 
1 hour later…
19:00
i reckon i'm inviting ridicule by asking this here but... does anyone have a regex handy to split the bound parameters from the statement text in sys.query_store_query_text.query_sql_text?
it might be easier from the query plan
is the xpath to the statement text always the same?
guess it'll be really obvious really quickly if not
WITH
    XMLNAMESPACES (DEFAULT 'http://schemas.microsoft.com/sqlserver/2004/07/showplan')
SELECT
    qsqt.query_sql_text,
    query_plan = TRY_CAST(qsp.query_plan AS xml),
    query_statistics_compiled_parameters =
        TRY_CAST(qsp.query_plan AS xml).query('//ParameterList/ColumnReference')
FROM sys.query_store_plan AS qsp
JOIN sys.query_store_query AS qsq
  ON qsp.query_id = qsq.query_id
JOIN sys.query_store_query_text AS qsqt
  ON qsq.query_text_id = qsqt.query_text_id
WHERE qsq.query_parameterization_type_desc = N'User';
should get you going
a gentleman and a scholar 🧐
ty
19:20
if that doesn't get you far enough
WITH
    XMLNAMESPACES (DEFAULT 'http://schemas.microsoft.com/sqlserver/2004/07/showplan'),
    p AS
(
    SELECT
        qsqt.query_sql_text,
        query_plan = TRY_CAST(qsp.query_plan AS xml)
    FROM sys.query_store_plan AS qsp
    JOIN sys.query_store_query AS qsq
      ON qsp.query_id = qsq.query_id
    JOIN sys.query_store_query_text AS qsqt
      ON qsq.query_text_id = qsqt.query_text_id
    WHERE qsq.query_parameterization_type_desc = N'User'
)
SELECT
    p.*,
    parameter = qp.p.value('@Column', 'sysname'),
19:47
DECLARE @result int;
EXEC @result = sp_getapplock @Resource = '__EFMigrationsLock', @LockOwner = 'Session', @LockMode = 'Exclusive';
SELECT @result

IF OBJECT_ID(N'[__EFMigrationsHistory]') IS NULL
BEGIN
    CREATE TABLE [__EFMigrationsHistory] (
        [MigrationId] nvarchar(150) NOT NULL,
        [ProductVersion] nvarchar(32) NOT NULL,
        CONSTRAINT [PK___EFMigrationsHistory] PRIMARY KEY ([MigrationId])
    );
END;

SELECT [MigrationId], [ProductVersion]
FROM [__EFMigrationsHistory]
ORDER BY [MigrationId];
As of EF Core 9, EF is using sp_getapplock when deploying migrations.
I hadn't heard that before. Just noticed it while I was running an app locally.
20:00
Is there any reasoning for that
20:13
why can't people let sp_getapplock die
Also interesting they get the result and proceed to do absolutely nothing to check it
it's great when you need something to do exactly what it does
Applocks only apply to anyone checking applocks, they don't truly lock anything
1 min ago, by Erik Reasonable Rates Darling
it's great when you need something to do exactly what it does
i've used it a bunch of times and it was great
zero complaints
read the docs
prevented concurrent processes from stepping all over each other and deadlocking constantly
20:19
You heard it here first, folks! Erik has ZERO complaints!
That's the kind of stuff that should have made the databases monthly video
they didn't check with me
TYPICAL
i wonder how peter is doing with my wonderful query
i hope he's well
@ErikReasonableRatesDarling It's there in case you have two instances of a web app starting up at the same time - to prevent them deploying migrations to the same DB at the same time.
@SeanGallardy I think the EF core guts do something with it, just not anything that shows up in the T-SQL.
so uh
is there a lock timeout
meaning i hope the second session doesn't just sit about waiting and then proceed with (trying?) to make all the same changes a second time
i suppose it's a good thing that you can't make a n/varchar column an identity

« first day (5162 days earlier)