Connecter Azure SQL vers Excel, Google Sheets, l'IA et REST

Ce qu'Azure voit lorsque l'agent se connecte

Azure SQL est un service partagé qui définit les utilisateurs autorisés à interagir avec lui ; il est donc important de préciser les données qui y sont stockées.

• La connectivité est testée via TCP avant toute tentative de connexion ; ainsi, un nom de serveur incorrect ou un chemin bloqué est considéré comme un problème réseau plutôt que comme un échec de connexion à Azure.
• Le regroupement des connexions est désactivé. Aucune session inactive ne s'accumule sur votre base de données entre les requêtes. — ce qui, sur une architecture sans serveur, correspond à la différence entre rester en pause et rester éveillé.
• Le refus propre au pare-feu Azure est reconnu pour ce qu'il est ; ainsi, un serveur qui n'a pas été informé de votre adresse signale un blocage réseau plutôt qu'une défaillance générique.
• Chaque connexion à Azure SQL est chiffrée, car Azure exige le protocole TLS et refuse tout autre protocole. Cette garantie est offerte par Azure et non négociée par l'agent en son nom.

Sans serveur, et la première requête après une pause

C’est le seul point faible qu’il vaut mieux connaître avant de le rencontrer, car le symptôme ressemble à une connexion défectueuse, alors qu’il n’en est rien.

• Une base de données sans serveur se met automatiquement en pause lorsqu'elle est inactive, et sa réactivation prend du temps, le temps que la tentative de connexion attende.
• L'agent attend 30 secondes pour se connecter et 35 secondes avant qu'une requête ne commence à répondre. Un réveil à froid peut dépasser ce délai.
• Il n'y a pas de nouvelle tentative automatique ; par conséquent, la première requête après une longue pause peut expirer et nécessiter une seconde exécution. Tout se déroule ensuite normalement.
• Une base de données en pause est reconnue comme telle plutôt que signalée comme manquante ; le message vous indique donc ce qui s'est réellement passé.

Il s'agit de SQL Server, avec deux mises en garde concernant Azure.

Le dialecte, les types et la structure du schéma sont identiques à ceux de n'importe quel autre serveur SQL, ce qui justifie son utilisation. Deux éléments diffèrent.

• Le schéma par défaut est dbo, et c'est ce que contient une référence inter-sources. — azure_sql.dbo.commandes.
• L'authentification Windows et Microsoft Entra n'est pas prise en charge ; l'agent propose une connexion SQL.
• Azure SQL Database ne prend pas en charge les requêtes T-SQL inter-bases de données. Par conséquent, l'option permettant d'interroger une seconde base de données sur la même connexion est bloquée pour ces hôtes. Cela n'affecte en rien les requêtes inter-sources. — Ces éléments sont assemblés par des flux de requêtes via des connexions distinctes, de sorte que la jonction d'une base de données Azure SQL à n'importe quel autre système fonctionne normalement.
• L'instance gérée partage le même suffixe de nom d'hôte et se connecte de la même manière ; il n'y a pas de carte séparée ni de comportement exclusif à l'instance gérée.

-- Requête T-SQL ordinaire, en lecture seule, contre le service géré SELECT TOP (50) c.Name, COUNT(o.OrderId) AS Orders, SUM(o.Amount) AS Revenue FROM dbo.Customers AS c JOIN dbo.Orders AS o ON o.CustomerId = c.CustomerId WHERE o.PlacedAt >= DATEADD(day, -30, SYSUTCDATETIME()) GROUP BY c.Name ORDER BY Revenue DESC;