The Bit Bucket

In KQL, projections are how you shape your dataset — deciding which columns to keep, how to name them, and even adding new ones on the fly.

The main operator for this is project. It lets you select only the columns you need, and at the same time, you can rename columns using aliases to make your results more meaningful or easier to read. For example:

Events
| project Time = Timestamp, User = UserId, Message

Here, the column Timestamp is renamed to Time, and UserId becomes User. This makes your results cleaner and easier to understand — especially when you’re building queries for dashboards or reports.

2026-06-12

When you visit websites, you may or may not have noticed the small icons that appear in the title bar areas. These are called Favicons. Here’s an example of one in Chrome:

In browsers, they appear in several places:

They are only a small visible aspect of your website but they greatly improve how professional the site looks in a browser. In some browsers, they also appear when you open a new page:

2026-06-11

When we start working with large volumes of data, one of the first and most important things we need to do is filter. Filtering is all about reducing noise — narrowing down the data that we really need so that we only keep the rows that are relevant to our analysis or our business needs.

In most systems, rows contain a mix of everything: normal activity, background data, edge cases, and sometimes even junk messages. If we tried to process or visualize all of it, our queries would slow down, and costs would rise, and the signal we care about would get buried in the noise. Filtering allows us to focus only on what matters.

2026-06-10

A question came up from a developer yesterday. He could see how to set a transaction isolation level but didn’t know how to determine the current transaction isolation level. That detail is available in the sys.dm_exec_sessions DMV.

Here’s an example:

SELECT COALESCE(CHOOSE(transaction_isolation_level,
                       'Read Uncommitted',
                       'Read Committed',
                       'Repeatable Read',
                       'Serializable',
                       'Snapshot'),
                'Unspecified') AS CurrentTransactionIsolationLevel
FROM sys.dm_exec_sessions  
WHERE session_id = @@SPID;

2026-06-09

Let’s look at how a basic KQL query is structured.

Every KQL query starts with a table — that’s your starting dataset, like Events, Logs, or Telemetry. From there, you build a pipeline of operations using the pipe (|) symbol, which passes the output of one operation into the next.

The most common first step is to filter the data using the where operator. It works just like a SQL WHERE clause but uses a more natural, functional syntax. For example:

2026-06-08

I had a lot of good feedback on my recent post about how to query group membership for a given login.

One tricky additional question was about how you could let a specfic user be able to find the group membership for another login, without the user being a sysadmin to run the code.

Now doing that is a bit trickier but can be done by creating a certificate, a login from the certificate, then assigning permissions to that login, and finally applying a digital signature to the procedure using the certificate.

2026-06-07

It’s time to look at what makes KQL different from traditional query languages.

At its foundation, KQL works with tables, rows, and columns, just like SQL. The structure feels familiar, but the query model is quite different.

KQL queries are built from operators — like where, summarize, project, and extend — and these are chained together using the pipe (|) symbol. Each operator takes the output of the previous one and transforms it further. It’s like building a data pipeline, one step at a time. This makes it incredibly readable and modular — you can easily add, remove, or rearrange steps without rewriting the whole query.

2026-06-06

BACKUP TO URL was introduced as an add-on in Cumulative Update 2 for SQL Server 2012 Service Pack 1 and as a built-in feature for SQL Server 2014. I’ve talked about it in previous blog posts.

We have been using this in a variety of ways from on-premises systems:

For example, it is an easy way to distribute a backup of a database to a large number of systems. Imagine you have a chain of retail stores that needs product and other reference information updated regularly. You can keep this data in a separate database at the head office, back it up to an Azure Storage account, and have each store download it separately.  This has major bandwidth and reliability improvements over other solutions such as having each store maintain a VPN connection to the head office.

2026-06-05

KQL, or Kusto Query Language, is a read-only, declarative query language.

Unlike SQL, which is procedural and typically runs in relational systems, KQL is pipeline-based. Each operation feeds directly into the next using the pipe (|) operator. This makes it incredibly intuitive once you get used to it — you start with a dataset, apply filters, transformations, and aggregations step by step, building your query like a flow of operations.

2026-06-04

I saw a question on a SQL Server mailing list about how to determine the Windows groups for a given SQL Server login.

That’s actually easy for a sysadmin login, as they have IMPERSONATE permission for other logins/users.

Here is an example procedure:

USE tempdb;
GO

CREATE OR ALTER PROCEDURE dbo.GetGroupsForALogin
@LoginName sysname
AS
BEGIN
    EXECUTE AS Login = @LoginName;

    SELECT [name] AS GroupName,
           usage AS Usage
    FROM sys.login_token 
    WHERE [type] = N'WINDOWS GROUP';
END;
GO

When I executed this on one of my SQL Server 2025 systems this way:

2026-06-03