Azure SQL | The .NET Blog

NL2SQL è la SQL Injection dell'Era Agentiva

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

C’è una versione del discorso su NL2SQL che suona perfetta: gli utenti fanno domande in linguaggio naturale, gli agenti generano SQL, i dati tornano. Meno schermate, meno query, meno codice. Semplice.

Poi ci pensi per altri cinque minuti.

I Problemi di cui Nessuno Parla nella Demo

Gli schemi non sono stati progettati per spiegare le cose. Nomi di tabelle criptici, nomi di colonne incoerenti, relazioni tecnicamente valide ma semanticamente invalide senza predicati aggiuntivi — questo è normale per i database aziendali. Non sono bug, sono semplicemente la storia accumulata dei cambiamenti di business. Ma quando chiedi a un modello di inferire l’intento da uno schema che non è stato progettato per comunicare l’intento, il modello ci proverà comunque. Non si arrenderà. Genererà la sua migliore query possibile e restituirà risultati con sicurezza.

I modelli non sono deterministici. Fai la stessa domanda sullo stesso database due volte e potresti ottenere SQL diverso. Il modello sta calcolando probabilità, e lievi variazioni nel contesto producono output diversi. Non puoi testare fino ad ottenere la garanzia che l’agente generi sempre la query corretta.

La revisione dell’utente non scala. “Basta rivedere ogni query prima dell’esecuzione” sembra sicuro. Ma presuppone che gli utenti siano esperti sia nel modello di dati che in SQL — esattamente le persone che non avevano bisogno dell’interfaccia in linguaggio naturale. Introduce anche sovraccarico cognitivo e una nuova classe di bias di conferma, dove gli utenti sopraffatti dalla complessità della query approvano query non valide invece di investigarle.

E poi c’è l’injection. Nello sviluppo SQL tradizionale, la parametrizzazione ha risolto l’injection perché l’input dell’utente riempiva i parametri, non la struttura SQL. Con NL2SQL, il modello genera il SQL stesso. Il prompt, il contesto dello schema, la cronologia della conversazione e i dati recuperati influenzano tutti ciò che viene eseguito. Se qualcuno elabora un prompt che cambia ciò che il modello genera, questa è injection — non a livello di parametro, ma a livello di generazione di query. E a differenza dell’eliminazione di una tabella (ovvio, recuperabile), l’injection NL2SQL produce query che restituiscono risultati errati senza errori visibili. Le decisioni aziendali vengono prese su dati sbagliati.

Cosa Risolve Realmente SQL MCP Server

È qui che l’articolo fa il suo punto pratico più utile. Invece di dare a un agente accesso arbitrario allo schema e sperare nel meglio, SQL MCP Server espone una superficie API curata costruita su Data API builder.

La differenza è importante: l’agente non genera SQL. Chiama endpoint denominati che restituiscono forme di risultato predefinite. Il SQL viene scritto una volta, da uno sviluppatore, ed è deterministico. Il non-determinismo dell’agente è limitato alla scelta di quale endpoint chiamare, non alla costruzione di query arbitrarie.

Questo è analogo a ciò che la parametrizzazione ha fatto per l’injection SQL nel modello di app tradizionale — rimuovi la capacità di costruire query arbitrarie dall’input non attendibile.

La Domanda Giusta

L’articolo non dice “non usare mai NL2SQL.” Dice: sii deliberato su dove lo applichi e cosa esponi. Per l’analisi esplorativa in un ambiente controllato, con uno schema limitato e accesso in sola lettura, NL2SQL potrebbe andare bene. Per i sistemi di produzione dove le decisioni aziendali dipendono dai risultati, un livello API curato è significativamente più sicuro.

Onestà: alcuni problemi si risolvono genuinamente meglio con query strutturate dietro endpoint denominati che con il linguaggio naturale verso SQL. SQL MCP Server ti dà questa opzione senza abbandonare completamente l’interfaccia agentiva.

Post originale: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

Azure SQL Può Ora Generare Embedding — In T-SQL Puro, Senza Livello Applicativo

Emiliano Montesdeoca — Fri, 22 May 2026 00:00:00 +0000

Se hai mai costruito una pipeline RAG, conosci la tassa della pipeline: i tuoi dati vivono in SQL, ma per generare embedding devi estrarli, chiamare un’API di embedding, gestire il batching e i limiti di velocità, e archiviare i risultati da qualche parte con ricerca vettoriale. Spesso in un database completamente diverso.

Azure SQL ha appena eliminato la maggior parte di questo con due funzionalità ora generalmente disponibili: CREATE EXTERNAL MODEL e AI_GENERATE_EMBEDDINGS.

Cosa Fanno

Queste due funzionalità T-SQL lavorano come una pipeline integrata:

CREATE EXTERNAL MODEL — registra un endpoint di modello AI esterno come oggetto di database con nome. Imposti la posizione, il formato API, il tipo di modello e le credenziali una volta sola. Riutilizzalo ovunque.

AI_GENERATE_EMBEDDINGS — una funzione T-SQL scalare che chiama il modello registrato e restituisce un array JSON di valori vettoriali. Funziona nelle istruzioni SELECT, INSERT, UPDATE e MERGE.

Insieme formano una pipeline di embedding end-to-end senza lasciare il motore SQL.

Il Flusso di Lavoro Completo

-- Passo 1: Registra il tuo fornitore di embedding una volta
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
 LOCATION = 'https://your-aoai-resource.openai.azure.com/',
 API_FORMAT = 'Azure OpenAI',
 MODEL_TYPE = EMBEDDINGS,
 MODEL = 'text-embedding-ada-002'
);

-- Passo 2: Genera embedding inline in T-SQL
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- Passo 3: Cerca con la distanza vettoriale
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

Questa è l’intera pipeline: dati in SQL, embedding generati in SQL, ricerca per similarità in SQL. Nessun livello di orchestrazione, nessun ETL, nessun database vettoriale separato.

Formati API e Opzioni Supportate

In GA, API_FORMAT supporta Azure OpenAI e OpenAI. MODEL_TYPE è bloccato su EMBEDDINGS per ora. Il JSON PARAMETERS consente di impostare valori predefiniti a livello di modello incluso il conteggio dei tentativi:

PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'

L’autenticazione usa le credenziali del database, quindi i segreti rimangono fuori dal codice dell’applicazione.

Cosa Questo Abilita per le Applicazioni .NET

Per gli sviluppatori .NET che costruiscono funzionalità AI su dati SQL esistenti, questo è significativo. Non hai bisogno di:

Estrarre dati in un archivio intermedio per gli embedding
Gestire una pipeline di embedding esterna
Configurare un database vettoriale separato (anche se puoi usare Azure AI Search se vuoi un archivio vettoriale completo)
Modificare il livello di accesso ai dati della tua applicazione

Puoi aggiungere la ricerca semantica alle applicazioni SQL esistenti in modo incrementale, usando gli stessi strumenti T-SQL che hai già.

Conclusione

I pattern RAG sui dati SQL sono diventati drammaticamente più semplici. AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL significa che la tua applicazione SQL esistente può acquisire capacità di ricerca vettoriale senza aggiungere nuova infrastruttura.

Entrambe le funzionalità sono in GA in Azure SQL Database e Azure SQL Managed Instance oggi.

Post originale: Generate Embeddings Function and External Model Object Support Are Now Generally Available in Azure SQL

Azure Data Studio è stato ritirato: sposta il tuo flusso di Azure SQL su VS Code

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Azure Data Studio è stato ritirato il 6 febbraio 2025, con supporto fino al 28 febbraio 2026 — il sostituto consigliato è VS Code con l’estensione MSSQL.

Cosa installare

Tre elementi per iniziare:

Estensione MSSQL — cerca “SQL Server (mssql)” nel Marketplace di VS Code
Estensione SQL Database Projects — schema come codice, validazione della build, pubblicazione guidata
.NET 8 SDK — richiesto dal sistema di build; l’SDK mancante è il problema più comune al primo avvio

Migrare le connessioni e le impostazioni di ADS

L’estensione MSSQL include l’ADS Migration Toolkit, che gestisce la migrazione una tantum in un flusso guidato: connessioni salvate, gruppi di connessioni, impostazioni e tasti di scelta rapida vengono importati automaticamente.

Ripristinare la memoria muscolare del F5

Gli utenti di ADS si affidano a F5 per eseguire le query. Installa l’estensione MSSQL Database Management Keymap per recuperare i tasti di scelta rapida in stile ADS, incluso F5.

SQL Database Projects: schema come codice

Clic destro su un progetto → Pubblica → configura la destinazione → rivedi lo script T-SQL generato → distribuisci. L’anteprima dello script prima del deployment è la funzionalità di sicurezza chiave. I modelli di elementi generano stub per tabelle, stored procedure e viste — lo stesso flusso di SSDT.

Problema frequente: un’incompatibilità della piattaforma di destinazione nel file .sqlproj causerà errori di build se il progetto è stato creato per una versione diversa di SQL Server.

Schema Compare e Schema Designer

L’estensione include anche Schema Compare (differenza tra il progetto e il database distribuito) e Schema Designer (modifica visuale dello schema senza scrivere DDL a mano).

Sviluppatori di Microsoft Fabric

La configurazione è identica, ma inizia dal portale Fabric e connetti prima il database a Git prima di aprirlo in VS Code. Microsoft ha una guida dedicata: Azure Data Studio to VS Code — What it means for SQL database in Fabric developers.

In conclusione

La migrazione è un flusso guidato una tantum, non una ricostruzione manuale. Installa i tre strumenti, esegui l’ADS Migration Toolkit, ripristina i tuoi tasti di scelta rapida e sarai di nuovo operativo in meno di 10 minuti.

Consulta l’articolo completo per screenshot passo-passo e la guida specifica per Fabric.

SQL MCP Server su Azure App Service — Senza Container

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Questo articolo è stato tradotto automaticamente. Per la versione originale, clicca qui.

Diciamoci la verità: ogni volta che vedo “richiede un container” in un tutorial, una piccola parte di me sospira. I container sono fantastici — finché il tuo team non ha una strategia per i container, e improvvisamente una funzionalità che sembrava semplice è bloccata da complessità di orchestrazione che nessuno aveva pianificato.

Ecco perché questo mi ha colpito. Il SQL MCP Server ora può girare su Azure App Service — senza Docker, senza Kubernetes, solo con la stessa configurazione di Data API Builder (DAB) che espone il tuo database SQL tramite MCP, REST e GraphQL.

Cos’è il SQL MCP Server?

Contesto rapido se non lo conosci ancora. Il SQL MCP Server si trova tra il tuo agente AI e il tuo database SQL. Invece di dare all’agente accesso diretto al database (un’idea pessima), espone le tue tabelle e view come uno strato di astrazione — entità con permessi definiti.

È costruito su Data API Builder, il che significa che un singolo file di configurazione gestisce MCP e REST e GraphQL contemporaneamente. Il tuo agente parla con l’endpoint MCP. La tua applicazione tradizionale parla con REST o GraphQL. Stessa config, stesso runtime, superfici diverse.

Questo è genuinamente utile. Non stai mantenendo due strati API separati.

Il Problema del Container (e la Soluzione)

Il modello di deployment originale del SQL MCP Server usava i container. Funziona bene in molti team — ma non in tutti. Molti team .NET standardizzano su Azure App Service o VM. Richiedere un runtime di container solo per esporre un endpoint SQL aggiunge attrito che nessuno ha chiesto.

Il nuovo walkthrough mostra come saltare completamente il container. Tutto funziona con un comando dab start, ospitato su App Service come un processo web .NET 8 standard.

# Installare Data API Builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Inizializzare la configurazione
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Aggiungere un'entità
dab add products --source dbo.products --permissions "authenticated:*"

# Configurare il provider di autenticazione App Service
dab configure --runtime.host.authentication.provider AppService

# Avviare il server
dab start

A questo punto hai MCP su /mcp, REST e GraphQL dallo stesso processo, e niente che gira in un container.

Autenticazione Senza Chiavi API Condivise

Questa è la parte che apprezzo di più. Quando fai il deploy su App Service, configuri Microsoft Entra ID come provider di autenticazione. Nessun segreto condiviso nei file di configurazione, nessuna chiave API da ruotare.

La stringa di connessione rimane in una variabile d’ambiente di App Service (non in dab-config.json), e l’endpoint MCP è protetto dall’autenticazione della piattaforma. Se sei già allineato con Entra ID nei tuoi workload Azure, questo si integra naturalmente.

Per lo sviluppo locale, passi alla modalità Simulator e al trasporto STDIO. Torni alla modalità AppService prima del deployment. Pulito ed esplicito.

Deploy su App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Poi fai il deploy del tuo progetto DAB usando il metodo di deployment del codice che il tuo team già utilizza. Il dettaglio chiave: è un deployment di codice, non di container.

Perché Importa per gli Sviluppatori .NET

Se stai costruendo agenti AI in .NET, prima o poi il tuo agente dovrà comunicare con un database. Il SQL MCP Server ti dà un modo strutturato per farlo senza esporre stringhe di connessione grezze.

Consulta il tutorial completo nel post originale e il repository di esempio su GitHub.

Conclusione

Il SQL MCP Server su App Service è una solida opzione pragmatica per i team .NET che vogliono dare ai propri agenti accesso strutturato ai dati SQL senza una strategia di container. Provalo — i tuoi agenti apprezzeranno la superficie API pulita.

SQL MCP Server — Il modo giusto per dare accesso ai database agli agenti AI

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Siamo onesti: la maggior parte dei server MCP per database disponibili oggi sono spaventosi. Prendono una query in linguaggio naturale, generano SQL al volo e lo eseguono contro i tuoi dati di produzione. Cosa potrebbe andare storto? (Tutto. Tutto potrebbe andare storto.)

Il team di Azure SQL ha appena presentato SQL MCP Server, e adotta un approccio fondamentalmente diverso. Costruito come funzionalità di Data API builder (DAB) 2.0, dà agli agenti AI un accesso strutturato e deterministico alle operazioni sul database — senza NL2SQL, senza esporre il tuo schema, e con RBAC completo ad ogni passaggio.

Perché non NL2SQL?

Questa è la decisione di design più interessante. I modelli non sono deterministici, e le query complesse sono le più propense a produrre errori sottili. Le query esatte che gli utenti sperano che l’AI possa generare sono anche quelle che richiedono più scrutinio quando prodotte in modo non deterministico.

Invece, SQL MCP Server usa un approccio NL2DAB. L’agente lavora con il livello di astrazione delle entità di Data API builder e il suo query builder integrato per produrre T-SQL accurato e ben formato in modo deterministico. Stesso risultato per l’utente, ma senza il rischio di JOIN allucinati o esposizione accidentale di dati.

Sette strumenti, non settecento

SQL MCP Server espone esattamente sette strumenti DML, indipendentemente dalle dimensioni del database:

describe_entities — scoprire entità e operazioni disponibili
create_record — inserire righe
read_records — interrogare tabelle e viste
update_record — modificare righe
delete_record — rimuovere righe
execute_entity — eseguire stored procedure
aggregate_records — query di aggregazione

Questo è intelligente perché le finestre di contesto sono lo spazio di pensiero dell’agente. Inondarle con centinaia di definizioni di strumenti lascia meno spazio per il ragionamento. Sette strumenti fissi mantengono l’agente concentrato sul pensare piuttosto che sul navigare.

Ogni strumento può essere abilitato o disabilitato individualmente:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Iniziare in tre comandi

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Ecco un SQL MCP Server funzionante che espone la tua tabella Customers. Il livello di astrazione delle entità significa che puoi creare alias per nomi e colonne, limitare i campi per ruolo e controllare esattamente cosa vedono gli agenti — senza esporre dettagli interni dello schema.

La storia della sicurezza è solida

Qui è dove la maturità di Data API builder ripaga:

RBAC ad ogni livello — ogni entità definisce quali ruoli possono leggere, creare, aggiornare o eliminare, e quali campi sono visibili
Integrazione con Azure Key Vault — stringhe di connessione e segreti gestiti in modo sicuro
Microsoft Entra + OAuth personalizzato — autenticazione di livello produzione
Content Security Policy — gli agenti interagiscono attraverso un contratto controllato, non SQL grezzo

L’astrazione dello schema è particolarmente importante. I nomi interni delle tue tabelle e colonne non vengono mai esposti all’agente. Definisci entità, alias e descrizioni che hanno senso per l’interazione AI — non il tuo diagramma ERD del database.

Multi-database e multi-protocollo

SQL MCP Server supporta Microsoft SQL, PostgreSQL, Azure Cosmos DB e MySQL. E poiché è una funzionalità di DAB, ottieni endpoint REST, GraphQL e MCP simultaneamente dalla stessa configurazione. Stesse definizioni di entità, stesse regole RBAC, stessa sicurezza — su tutti e tre i protocolli.

L’auto-configurazione in DAB 2.0 può persino ispezionare il tuo database e costruire la configurazione dinamicamente, se sei a tuo agio con meno astrazione per la prototipazione rapida.

La mia opinione

Ecco come dovrebbe funzionare l’accesso aziendale ai database per gli agenti AI. Non “hey LLM, scrivimi un po’ di SQL e YOLO sulla produzione.” Invece: un livello di entità ben definito, generazione deterministica delle query, RBAC ad ogni passaggio, caching, monitoraggio e telemetria. È noioso nel miglior modo possibile.

Per gli sviluppatori .NET, la storia dell’integrazione è pulita — DAB è uno strumento .NET, l’MCP Server gira come container, e funziona con Azure SQL, che la maggior parte di noi sta già usando. Se stai costruendo agenti AI che hanno bisogno di accesso ai dati, inizia qui.

Conclusione

SQL MCP Server è gratuito, open-source e gira ovunque. È l’approccio prescrittivo di Microsoft per dare agli agenti AI un accesso sicuro ai database. Consulta il post completo e la documentazione per iniziare.