Press "Enter" to skip to content

Day: June 16, 2026

Anonymizing PII in Language Model Pipelines

Published 2026-06-16 by Kevin Feasel

Dejan Lukic tries to minimize personally identifiable information:

Large language models (LLMs) and the agents built on top of them ingest everything they are given, including personally-identifiable information (PII). In workflows where PII is inevitable, proper measures should exist for data sanitization.

Data can leak through model outputs, embeddings or even logs. Given that you have to use LLMs in your pipeline, in this article I will cover the anonymization techniques you can utilize in an LLM flow to minimize PII exposure vectors.

Some of the points are specific to language models (or at least storing data in vector databases), but other tips are more generic and can apply to classic data handling.

Comments closed

Multilingual Reports in Power BI

Published 2026-06-16 by Kevin Feasel

Reza Rad solves a common challenge:

Building a multilingual Power BI report has always been one of those requirements that sounded simple but turned out painful to implement. A French-speaking user opens your report and sees English category names. A Spanish-speaking user opens the same report and sees the same English values. You end up either maintaining multiple reports — one per language — or wrestling with external tools and complex workarounds just to get translations working properly.

Read on for an alternative solution that is—you guessed it—currently in preview.

Comments closed

Things to Watch with Contained Availability Groups

Published 2026-06-16 by Kevin Feasel

John Morehouse keeps one eye on things:

Contained availability groups solve some real operational problems, especially around logins, jobs, permissions, and supporting metadata. They can reduce drift between replicas and make failover cleaner.

That does not mean they are magic.

Like most SQL Server features, contained availability groups come with details that matter. The feature can absolutely help, but it needs to be designed, tested, and operated with the right expectations.

Click through for several things you should consider before jumping into deploying contained AGs.

Comments closed

Solving Kusto Detective Academy Case 4

Published 2026-06-16 by Kevin Feasel

Tom Zika wears a trench coat and works out of a run-down office in a mess of a town, all in black and white:

Someone hacked into Digitown’s municipality, stole classified documents, and vanished. All we have is 30 days of router logs and a lookup table. Time to find a needle in 45 million rows of hay.

I really like the work the Kusto team has put into Kusto Detective Academy. Tom’s blog post is a spoiler if you want to answer it yourself, of course.

Comments closed

Microsoft.Data.SqlClient Connection error in SSIS 2025

Published 2026-06-16 by Kevin Feasel

Andy Leonard troubleshoots (with assistance from Claude) a tricky error:

Recently, I was developing an SSIS package that read from an Azure SQL DB table and wrote to an on-premises SQL Server 2025 database table. I encountered the following error:

[ADO NET Source [41]] Error: ADO NET Source has failed to acquire the connection {<ConnectionManagerGUID>} with the following error message: “Could not load file or assembly ‘Microsoft.Data.SqlClient, Version=6.0.0.0, Culture=neutral, PublicKeyToken=<PublicKeyToken>’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)”.

The issue has nothing to do with a missing file or assembly.

Comments closed

Postgres NULLs and NOT IN

Published 2026-06-16 by Kevin Feasel

Radim Marek lays out a common issue people experience in PostgreSQL:

A NOT IN query can return the wrong answer without telling you. It is valid SQL, it runs without an error, and it hands back a perfectly well-formed result set that happens to be empty when it should not be. No warning, no hint, nothing in the logs: just zero rows where you expected hundreds, and a database that considers it correct.

Almost always the cause is a single NULL sitting somewhere you forgot to look, combined with two keywords you have typed a thousand times: NOT IN. None of it is a Postgres bug. This is exactly what the SQL standard mandates, implemented faithfully. That is precisely what makes it so easy to walk into, and why the planner could not safely optimize around it for the better part of Postgres’s history. It comes down to one if statement in the parser.

This is a Postgres-specific problem, as the same code runs successfully in SQL Server. But if you are working with Postgres, it’s good to keep track of this behavior, and Radim has solid advice for a proper workaround.

2 Comments