Why is fn_xe_file_target_read_file the worst SQL function?
Why SQL Server's fn_xe_file_target_read_file is so frustrating: an nvarchar(max) return type, broken timestamp filtering, and no efficient way to find rollover files.
Long-form notes on TSQL performance, Extended Events, Query Store and the tooling around them. Written from the trenches, not the slide deck.
Why SQL Server's fn_xe_file_target_read_file is so frustrating: an nvarchar(max) return type, broken timestamp filtering, and no efficient way to find rollover files.
When I'm looking at a query, I bet it's bad if I see... a shopping list of red flags I've learned to spot, from AI-generated code to SSMS map mode gut checks.
A deleted podcast episode, 17 million archive log entries, and KQL's time series analysis to find the backup that was never supposed to survive.
Someone hacked Digitown's municipality and stole classified documents. 45 million rows of router traffic, an IP lookup table, and KQL's anomaly detection to find who did it.
I trusted AI to redesign this blog, be my personal assistant, and organize my life. But I won't let it near a production database. Here's why that's not a contradiction - and what I learned about trust along the way.
What does SQL Server actually see when it parses your code? I built a free web tool that lets you paste TSQL and explore the abstract syntax tree - click a token, see the node, read the fragment.
20 stolen cars with swapped license plates - using KQL to trace VIN changes through traffic data and find the common storage location.
Digitown's citizens are being targeted by phishing calls. Using KQL, I analyze call patterns - duration, hidden caller IDs, and disconnect behavior - to unmask the phisher.