Press "Enter" to skip to content

Day: June 2, 2026

Hosting an Local Embedding Service for SQL Server 2025

Greg Low has a demo:

Instead of working directly with text, images, or other rich content, an embedding represents that content as a set of numbers that capture semantic relationships learned by a model. This lets systems work with meaning in a mathematical way rather than relying on concepts like text matching.

Embeddings are the output of trained text-based AI models. One possibly surprising concept is that they’re used for similarity, as opposed to facts – and for relative closeness instead of exact matches.

SQL Server is not designed to host or execute those models. This isn’t a limitation; it is a design choice. While it would be possible to run code within SQL Server to generate embeddings, it just wouldn’t be a good idea.

Note that SQL Server can already run machine learning models directly, and use the PREDICT statement to make predictions. We don’t want to be doing that with the language models we need for embeddings, though.

There are also some really good local embedding models, and between that and the vector similarity functionality in SQL Server, you can perform semantic search without needing to reach out to an online service.

Leave a Comment

Choosing between ORMs vs Raw SQL

Jamal Hansen embraces the power of “and”:

At the beginning of this series, I promised that even if you know how to use an Object Relational Mapper (ORM) to interact with a database, knowing SQL would make you a better developer. Now that we have covered everything from SELECT to parameterized queries, it is time to answer the question that every Python developer eventually asks: when should I use an ORM, and when should I just write SQL?

I think there’s a reasonable split between the two, though the choice of ORM matters a lot as well. The heavier the ORM (nHibernate and Entity Framework, I’m looking at you), the more performance you’re trading off. By contrast, a micro-ORM like Dapper has a much slimmer profile, and if you combine that with judicious use of stored procedures for non-trivial work, the outcome is usually good.

Leave a Comment

Removing Filters from the Filter Context in DAX

Marco Russo and Alberto Ferrari compare a few techniques:

Computing values in DAX is all about understanding how to manipulate the filter context to obtain the desired output. DAX offers a wide variety of functions to manipulate the filter context, including a rich set designed to remove filters. Among the many, four are used the most: ALLALLSELECTEDALLEXCEPT, and REMOVEFILTERS. Choosing the right one can be tough.

In this article, we do not want to dive into too many details; the goal is to let our readers understand when to use which function. Whenever needed, we provide links to deepen your knowledge about specific topics. Make sure to read the additional content if you want to know more about some specific behaviors.

Click through for demonstrations and a contrast of these different techniques.

Leave a Comment

GraphQL Deployment Error due to dm_exec_describe_first_result_set()

Koen Verbeeck troubleshoots an issue:

A while ago we suddenly had an error while trying to deploy one Fabric workspace to another using fabric-cicd. The issue was with a GraphQL object and the following error was returned:

Failed to publish GraphQLApi ‘my_graphql’: Operation failed. Error Code: DatasourceInvalidStoredProcedure. Error Message: Only those stored procedures whose metadata for the first result set described by sys.dm_exec_describe_first_result_set are supported.

Read on for Koen’s diagnosis and resolution for this issue.

Leave a Comment