Verbinden Azure SQL zu Excel, Google Sheets, KI und REST

Was Azure sieht, wenn sich der Agent verbindet

Azure SQL ist ein gemeinsam genutzter Dienst, bei dem es Meinungen darüber gibt, wer mit ihm kommunizieren darf. Daher ist es wichtig, genau festzulegen, was ankommt.

• Die Erreichbarkeit wird über TCP geprüft, bevor ein Anmeldeversuch unternommen wird. Daher wird ein falscher Servername oder ein blockierter Pfad als Netzwerkproblem interpretiert, anstatt dass dies bei Azure als fehlgeschlagene Anmeldung angezeigt wird.
• Connection Pooling ist deaktiviert. Es werden keine inaktiven Sitzungen zwischen den Abfragen in Ihrer Datenbank angesammelt. — was auf einer serverlosen Ebene den Unterschied zwischen pausiertem Spiel und durchgehendem Spiel ausmacht.
• Die Ablehnung durch die Azure-Firewall wird als solche erkannt, sodass ein Server, dem Ihre Adresse nicht bekannt ist, eine Netzwerkblockade und keinen allgemeinen Fehler meldet.
• Jede Verbindung zu Azure SQL ist verschlüsselt, da Azure TLS vorschreibt und alles andere ablehnt. Diese Garantie wird von Azure selbst übernommen und nicht vom Agenten in dessen Namen ausgehandelt.

Serverlos und die erste Abfrage nach einer Pause

Dies ist der einzige Haken, den man kennen sollte, bevor man damit konfrontiert wird, denn das Symptom sieht aus wie eine unterbrochene Verbindung, ist es aber nicht.

• Eine serverlose Datenbank pausiert automatisch, wenn sie im Leerlauf ist, und das Aufwecken benötigt Zeit, die der Verbindungsversuch abwarten muss.
• Der Agent wartet 30 Sekunden, um eine Verbindung herzustellen, und 35 Sekunden, bis eine Anfrage beantwortet wird. Ein Kaltstart kann diese Zeit überschreiten.
• Es gibt keine automatische Wiederholungsfunktion. Daher kann es vorkommen, dass die erste Abfrage nach einer längeren Pause ein Timeout verursacht und erneut ausgeführt werden muss. Alles danach verläuft normal.
• Eine pausierte Datenbank wird als pausiert erkannt und nicht als fehlend gemeldet, sodass die Meldung Ihnen mitteilt, was tatsächlich passiert ist.

Es handelt sich um SQL Server, mit zwei Azure-ähnlichen Einschränkungen.

Der Dialekt, die Datentypen und das Schema-Layout sind identisch mit denen anderer SQL Server – genau das ist ja der Sinn der Sache. Zwei Dinge unterscheiden sich jedoch.

• Das Standardschema ist dbo, und genau das trägt eine quellenübergreifende Referenz. — azure_sql.dbo.orders.
• Windows- und Microsoft Entra-Authentifizierung werden nicht unterstützt; der Agent stellt eine SQL-Anmeldung bereit.
• Azure SQL-Datenbank verfügt über kein eigenes datenbankübergreifendes T-SQL, daher wird das Angebot, eine zweite Datenbank über dieselbe Verbindung abzufragen, für diese Hosts nicht bereitgestellt. Dies hat keinerlei Auswirkungen auf datenbankübergreifende Abfragen. — diese werden von Query Streams über separate Verbindungen hinweg zusammengestellt, sodass das Verbinden einer Azure SQL-Datenbank mit anderen Datenbanken normal funktioniert.
• Die verwaltete Instanz verwendet dasselbe Hostnamensuffix und wird auf dieselbe Weise verbunden; es gibt keine separate Karte und kein Verhalten, das nur für verwaltete Instanzen gilt.

-- Gewöhnliches T-SQL, schreibgeschützt, gegen den verwalteten Dienst 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;