Arbeta med frågemeddelanden
gäller för:
SQL ServerAzure SQL Managed Instance
Viktig
SQL Server Native Client (SNAC) levereras inte med:
- SQL Server 2022 (16.x) och senare versioner
- SQL Server Management Studio 19 och senare versioner
SQL Server Native Client (SQLNCLI eller SQLNCLI11) och den äldre Microsoft OLE DB-providern för SQL Server (SQLOLEDB) rekommenderas inte för ny programutveckling.
Använd någon av följande faktorer för nya projekt:
För SQLNCLI som levereras som en komponent i SQL Server Database Engine (version 2012 till och med 2019), se det här Support Lifecycle exception.
Frågemeddelanden introducerades i SQL Server 2005 (9.x) och SQL Server Native Client. Baserat på den Service Broker-infrastruktur som introducerades i SQL Server 2005 (9.x) tillåter frågemeddelanden att program meddelas när data har ändrats. Den här funktionen är särskilt användbar för program som tillhandahåller en cache med information från en databas, till exempel ett webbprogram, och som måste meddelas när källdata ändras.
Med frågemeddelanden kan du begära meddelanden inom en angiven tidsgräns när underliggande data i en fråga ändras. Begäran om meddelande anger meddelandealternativen, som inkluderar tjänstnamnet, meddelandetexten och tidsgränsvärdet till servern. Meddelanden levereras via en Service Broker-kö som program kan söka efter tillgängliga meddelanden.
Syntaxen för frågemeddelandens alternativsträng är:
service=<service-name>[;(local database=<database> | broker instance=<broker instance>)]
Till exempel:
service=mySSBService;local database=mydb
Meddelandeprenumerationer överlever processen som initierar dem, eftersom ett program kan skapa en meddelandeprenumeration och sedan avsluta. Prenumerationen är giltig och meddelandet inträffar om data ändras inom den tidsgräns som angavs när prenumerationen skapades. Ett meddelande identifieras av den körda frågan, meddelandealternativen och meddelandetexten och kan avbrytas genom att dess timeout-värde anges till noll.
Meddelanden skickas bara en gång. För kontinuerliga meddelanden om dataändring måste en ny prenumeration skapas genom att köra frågan igen när varje meddelande har bearbetats.
SQL Server Native Client-program tar vanligtvis emot meddelanden med hjälp av kommandot Transact-SQL RECEIVE för att läsa meddelanden från kön som är associerad med den tjänst som anges i meddelandealternativen.
Not
Tabellnamn måste vara kvalificerade i frågor för vilka meddelanden krävs, till exempel dbo.myTable. Tabellnamn måste vara kvalificerade med två delnamn. Prenumerationen är ogiltig om namn i tre eller fyra delar används.
Meddelandeinfrastrukturen bygger på en köfunktion som introducerades i SQL Server 2005 (9.x). I allmänhet skickas meddelanden som genereras på servern via dessa köer som ska bearbetas senare.
Om du vill använda frågemeddelanden måste en kö och en tjänst finnas på servern. Dessa kan skapas med hjälp av Transact-SQL som liknar följande:
CREATE QUEUE myQueue
CREATE SERVICE myService ON QUEUE myQueue
([http://schemas.microsoft.com/SQL/Notifications/PostQueryNotification])
Not
Tjänsten måste använda det fördefinierade kontraktet http://schemas.microsoft.com/SQL/Notifications/PostQueryNotification enligt ovan.
SQL Server Native Client OLE DB-provider
SQL Server Native Client OLE DB-providern stöder konsumentmeddelanden om raduppsättningsändring. Konsumenten får ett meddelande i varje fas av raduppsättningsändringen och om eventuella ändringsförsök.
Not
Att skicka en meddelandefråga till servern med ICommand::Execute är det enda giltiga sättet att prenumerera på frågemeddelanden med SQL Server Native Client OLE DB-providern.
Egenskapsuppsättningen DBPROPSET_SQLSERVERROWSET
För att stödja frågemeddelanden via OLE DB lägger SQL Server Native Client till följande nya egenskaper i egenskapsuppsättningen DBPROPSET_SQLSERVERROWSET.
| Namn | Typ | Beskrivning |
|---|---|---|
| SSPROP_QP_NOTIFICATION_TIMEOUT | VT_UI4 | Antalet sekunder som frågemeddelandet ska vara aktivt. Standardvärdet är 432 000 sekunder (5 dagar). Minimivärdet är 1 sekund och det maximala värdet är 2^31–1 sekunder. |
| SSPROP_QP_NOTIFICATION_MSGTEXT | VT_BSTR | Meddelandetexten i meddelandet. Detta är användardefinierat och har inget fördefinierat format. Som standard är strängen tom. Du kan ange ett meddelande med 1–2 000 tecken. |
| SSPROP_QP_NOTIFICATION_OPTIONS | VT_BSTR | Alternativ för frågemeddelanden. Dessa anges i en sträng med namn=värde syntax. Användaren ansvarar för att skapa tjänsten och läsa meddelanden utanför kön. Standardvärdet är en tom sträng. |
Meddelandeprenumerationen har alltid checkats in, oavsett om instruktionen kördes i en användartransaktion eller i automatisk incheckning eller om transaktionen där -instruktionen kördes eller återställdes. Servermeddelandet utlöses på något av följande ogiltiga meddelandevillkor: ändring av underliggande data eller schema, eller när tidsgränsen nås; beroende på vilket som är först. Meddelanderegistreringar tas bort så snart de har utlösts. När du tar emot meddelanden måste programmet därför prenumerera igen om de vill få ytterligare uppdateringar.
En annan anslutning eller tråd kan kontrollera målkön för meddelanden. Till exempel:
WAITFOR (RECEIVE * FROM MyQueue); // Where MyQueue is the queue name.
Observera att SELECT * inte tar bort posten från kön, men TA EMOT * FRÅN gör det. Detta stoppar en servertråd om kön är tom. Om det finns köposter vid tidpunkten för samtalet returneras de omedelbart. annars väntar samtalet tills en köpost har gjorts.
RECEIVE * FROM MyQueue
Den här instruktionen returnerar omedelbart en tom resultatuppsättning om kön är tom. annars returneras alla köaviseringar.
Om SSPROP_QP_NOTIFICATION_MSGTEXT och SSPROP_QP_NOTIFICATION_OPTIONS är icke-NULL och icke-tomma skickas TDS-rubriken för frågemeddelanden som innehåller de tre egenskaper som definierats ovan till servern med varje körning av kommandot. Om någon av dem är null (eller tom) skickas inte rubriken och DB_E_ERRORSOCCURRED utlöses (eller DB_S_ERRORSOCCURRED om egenskaperna båda är markerade som valfria) och statusvärdet är inställt på DBPROPSTATUS_BADVALUE. Verifieringen sker vid Execute/Prepare. På samma sätt utlöses DB_S_ERRORSOCCURRED när frågemeddelandeegenskaperna anges för anslutningar till SQL Server-versioner före SQL Server 2005 (9.x). Statusvärdet i det här fallet är DBPROPSTATUS_NOTSUPPORTED.
Att initiera en prenumeration garanterar inte att efterföljande meddelanden levereras. Dessutom görs ingen kontroll av giltigheten för det angivna tjänstnamnet.
Not
Förberedelseinstruktioner kommer aldrig att leda till att prenumerationen initieras. endast instruktionskörning uppnår detta och frågemeddelanden påverkas inte av användningen av OLE DB-kärntjänster.
Mer information om egenskapsuppsättningen DBPROPSET_SQLSERVERROWSET finns i Egenskaper och beteenden för raduppsättningar.
SQL Server Native Client ODBC-drivrutin
SQL Server Native Client ODBC-drivrutinen stöder frågemeddelanden genom att lägga till tre nya attribut i SQLGetStmtAttr och SQLSetStmtAttr funktioner:
SQL_SOPT_SS_QUERYNOTIFICATION_MSGTEXT
SQL_SOPT_SS_QUERYNOTIFICATION_OPTIONS
SQL_SOPT_SS_QUERYNOTIFICATION_TIMEOUT
Om SQL_SOPT_SS_QUERYNOTIFICATION_MSGTEXT och SQL_SOPT_SS_QUERYNOTIFICATION_OPTIONS inte är NULL skickas TDS-rubriken för frågemeddelanden som innehåller de tre attributen som definierats ovan till servern varje gång kommandot körs. Om någon av dem är null skickas inte huvudet och SQL_SUCCESS_WITH_INFO returneras. Verifieringen sker på SQLPrepare Function, SqlExecDirectoch SqlExecute, som alla misslyckas om attributen inte är giltiga. På samma sätt misslyckas körningen med SQL_SUCCESS_WITH_INFO när dessa frågemeddelandeattribut anges för SQL Server-versioner före SQL Server 2005 (9.x).
Not
Prepare-instruktioner kommer aldrig att leda till att prenumerationen initieras. prenumerationen kan initieras genom instruktionskörning.
Specialfall och begränsningar
Följande datatyper stöds inte för meddelanden:
text
ntext
bild
Om en meddelandebegäran görs för en fråga som returnerar någon av dessa typer utlöses meddelandet omedelbart och anger att det inte var möjligt att skicka en meddelandeprenumeration.
Om en prenumerationsbegäran görs för en batch eller en lagrad procedur görs en separat prenumerationsbegäran för varje instruktion som körs i batchen eller den lagrade proceduren. EXECUTE-instruktioner registrerar inte ett meddelande, men skickar meddelandebegäran till det körda kommandot. Om det är en batch tillämpas kontexten på de körda instruktionerna och samma regler som beskrivs ovan gäller.
Om en fråga skickas för meddelanden som skickats av samma användare under samma databaskontext och har samma mall, samma parametervärden, samma meddelande-ID och samma leveransplats för en befintlig aktiv prenumeration, förnyas den befintliga prenumerationen och den nya angivna tidsgränsen återställs. Det innebär att om meddelandet begärs för identiska frågor skickas endast ett meddelande. Detta skulle gälla för en fråga som dupliceras i en batch eller en fråga i en lagrad procedur som anropades flera gånger.