Praca z powiadomieniami zapytania
Dotyczy:
programu SQL ServerAzure SQL Managed Instance
Ważny
klienta natywnego programu SQL Server (SNAC) nie jest dostarczany z:
- SQL Server 2022 (16.x) i nowsze wersje
- SQL Server Management Studio 19 i nowsze wersje
Program SQL Server Native Client (SQLNCLI lub SQLNCLI11) oraz starszy dostawca microsoft OLE DB dla programu SQL Server (SQLOLEDB) nie są zalecane w przypadku tworzenia nowych aplikacji.
W przypadku nowych projektów użyj jednego z następujących czynników:
- sterownik Microsoft ODBC dla programu SQL Server
- sterownik Microsoft OLE DB dla programu SQL Server
W przypadku programu SQLNCLI, który jest dostarczany jako składnik aparatu bazy danych programu SQL Server (wersje 2012–2019), zobacz ten wyjątek cyklu wsparcia .
Powiadomienia o zapytaniach zostały wprowadzone w programie SQL Server 2005 (9.x) i kliencie natywnym programu SQL Server. Oparta na infrastrukturze usługi Service Broker wprowadzonej w programie SQL Server 2005 (9.x) powiadomienia o zapytaniach umożliwiają aplikacjom powiadamianie o zmianie danych. Ta funkcja jest szczególnie przydatna w przypadku aplikacji, które udostępniają pamięć podręczną informacji z bazy danych, takiej jak aplikacja internetowa, i muszą być powiadamiane o zmianie danych źródłowych.
Powiadomienia dotyczące zapytań umożliwiają zażądanie powiadomienia w określonym przedziale czasu, gdy bazowe dane zapytania zmieniają się. Żądanie powiadomienia określa opcje powiadomień, które obejmują nazwę usługi, tekst komunikatu i wartość limitu czasu na serwerze. Powiadomienia są dostarczane za pośrednictwem kolejki usługi Service Broker, którą aplikacje mogą sondowania pod kątem dostępnych powiadomień.
Składnia ciągu opcji powiadomień zapytania to:
service=<service-name>[;(local database=<database> | broker instance=<broker instance>)]
Na przykład:
service=mySSBService;local database=mydb
Subskrypcje powiadomień przeżywają proces, który je inicjuje, ponieważ aplikacja może utworzyć subskrypcję powiadomień, a następnie zakończyć. Subskrypcja pozostaje prawidłowa, a powiadomienie zostanie wyświetlone, jeśli dane zmienią się w przedziale czasu określonym podczas tworzenia subskrypcji. Powiadomienie jest identyfikowane przez wykonane zapytanie, opcje powiadomień i tekst wiadomości i może zostać anulowane przez ustawienie wartości limitu czasu na zero.
Powiadomienia są wysyłane tylko raz. W przypadku ciągłego powiadamiania o zmianie danych należy utworzyć nową subskrypcję przez ponowne wykonanie zapytania po przetworzeniu każdego powiadomienia.
Aplikacje klienta natywnego programu SQL Server zwykle odbierają powiadomienia przy użyciu polecenia Transact-SQL RECEIVE do odczytu powiadomień z kolejki skojarzonej z usługą określoną w opcjach powiadomień.
Nuta
Nazwy tabel muszą być kwalifikowane w zapytaniach, dla których wymagane jest powiadomienie, na przykład dbo.myTable. Nazwy tabel muszą być kwalifikowane z dwiema częściami. Subskrypcja jest nieprawidłowa, jeśli są używane nazwy trzech lub czterech części.
Infrastruktura powiadomień jest oparta na funkcji kolejkowania wprowadzonej w programie SQL Server 2005 (9.x). Ogólnie rzecz biorąc, powiadomienia generowane na serwerze są wysyłane za pośrednictwem tych kolejek do przetworzenia później.
Aby można było używać powiadomień o zapytaniach, na serwerze musi istnieć kolejka i usługa. Można je utworzyć przy użyciu Transact-SQL podobnych do następujących:
CREATE QUEUE myQueue
CREATE SERVICE myService ON QUEUE myQueue
([http://schemas.microsoft.com/SQL/Notifications/PostQueryNotification])
Nuta
Usługa musi używać wstępnie zdefiniowanej umowy http://schemas.microsoft.com/SQL/Notifications/PostQueryNotification, jak pokazano powyżej.
Dostawca OLE DB natywnego klienta programu SQL Server
Dostawca OLE DB klienta natywnego programu SQL Server obsługuje powiadomienia konsumentów dotyczące modyfikacji zestawu wierszy. Odbiorca otrzymuje powiadomienie na każdej fazie modyfikacji zestawu wierszy i przy każdej próbie zmiany.
Nuta
Przekazywanie zapytania powiadomień do serwera przy użyciu ICommand::Execute jest jedynym prawidłowym sposobem subskrybowania powiadomień o powiadomieniach za pomocą dostawcy OLE DB klienta natywnego programu SQL Server.
Zestaw właściwości DBPROPSET_SQLSERVERROWSET
Aby obsługiwać powiadomienia o zapytaniach za pomocą ole DB, klient natywny programu SQL Server dodaje następujące nowe właściwości do zestawu właściwości DBPROPSET_SQLSERVERROWSET.
| Nazwa | Typ | Opis |
|---|---|---|
| SSPROP_QP_NOTIFICATION_TIMEOUT | VT_UI4 | Liczba sekund, przez które powiadomienie zapytania ma pozostać aktywne. Wartość domyślna to 432000 sekund (5 dni). Wartość minimalna to 1 sekunda, a maksymalna wartość to 2^31–1 sekundy. |
| SSPROP_QP_NOTIFICATION_MSGTEXT | VT_BSTR | Tekst wiadomości powiadomienia. Jest to zdefiniowane przez użytkownika i nie ma wstępnie zdefiniowanego formatu. Domyślnie ciąg jest pusty. Komunikat można określić przy użyciu 1–2000 znaków. |
| SSPROP_QP_NOTIFICATION_OPTIONS | VT_BSTR | Opcje powiadomienia zapytania. Są one określone w ciągu o nazwie =wartości składni. Użytkownik jest odpowiedzialny za tworzenie usługi i odczytywanie powiadomień poza kolejką. Wartość domyślna to pusty ciąg. |
Subskrypcja powiadomień jest zawsze zatwierdzana, niezależnie od tego, czy instrukcja została uruchomiona w transakcji użytkownika, czy w automatycznym zatwierdzeniu, czy też czy transakcja, w której instrukcja została zatwierdzona, czy wycofana. Powiadomienie serwera jest uruchamiane na dowolnym z następujących nieprawidłowych warunków powiadamiania: zmiana bazowych danych lub schematu lub po osiągnięciu limitu czasu; w zależności od tego, która wartość jest pierwsza. Rejestracje powiadomień są usuwane natychmiast po ich wyzwoleniu. W związku z tym po otrzymaniu powiadomień aplikacja musi ponownie zasubskrybować, jeśli chce uzyskać dalsze aktualizacje.
Inne połączenie lub wątek mogą sprawdzać kolejkę docelową pod kątem powiadomień. Na przykład:
WAITFOR (RECEIVE * FROM MyQueue); // Where MyQueue is the queue name.
Należy pamiętać, że funkcja SELECT * nie usuwa wpisu z kolejki, jednak funkcja RECEIVE * FROM. Spowoduje to zatrzymanie wątku serwera, jeśli kolejka jest pusta. Jeśli w momencie wywołania występują wpisy w kolejce, są one zwracane natychmiast; w przeciwnym razie wywołanie czeka na utworzenie wpisu kolejki.
RECEIVE * FROM MyQueue
Ta instrukcja natychmiast zwraca pusty zestaw wyników, jeśli kolejka jest pusta; w przeciwnym razie zwraca wszystkie powiadomienia kolejki.
Jeśli SSPROP_QP_NOTIFICATION_MSGTEXT i SSPROP_QP_NOTIFICATION_OPTIONS są inne niż NULL i niepuste, nagłówek TDS powiadomień o zapytaniach zawierający trzy zdefiniowane powyżej właściwości są wysyłane do serwera z każdym wykonaniem polecenia. Jeśli jeden z nich ma wartość null (lub jest pusty), nagłówek nie jest wysyłany i DB_E_ERRORSOCCURRED jest wywoływany (lub DB_S_ERRORSOCCURRED, jeśli właściwości są oznaczone jako opcjonalne), a wartość stanu jest ustawiona na DBPROPSTATUS_BADVALUE. Walidacja odbywa się na stronie Wykonaj/Przygotuj. Podobnie DB_S_ERRORSOCCURRED jest wywoływana, gdy właściwości powiadomienia zapytania są ustawione dla połączeń z wersjami programu SQL Server przed programem SQL Server 2005 (9.x). Wartość stanu w tym przypadku jest DBPROPSTATUS_NOTSUPPORTED.
Inicjowanie subskrypcji nie gwarantuje pomyślnego dostarczenia kolejnych komunikatów. Ponadto nie jest sprawdzana ważność określonej nazwy usługi.
Nuta
Przygotowywanie instrukcji nigdy nie spowoduje zainicjowania subskrypcji; Wykonanie tylko instrukcji spowoduje osiągnięcie tego celu, a powiadomienia o zapytaniach nie mają wpływu na użycie podstawowych usług OLE DB.
Aby uzyskać więcej informacji na temat zestawu właściwości DBPROPSET_SQLSERVERROWSET, zobacz Właściwości i zachowania zestawu wierszy.
Sterownik ODBC klienta natywnego programu SQL Server
Sterownik ODBC klienta natywnego programu SQL Server obsługuje powiadomienia o zapytaniach przez dodanie trzech nowych atrybutów do funkcji SQLGetStmtAttr i SQLSetStmtAt tr:
SQL_SOPT_SS_QUERYNOTIFICATION_MSGTEXT
SQL_SOPT_SS_QUERYNOTIFICATION_OPTIONS
SQL_SOPT_SS_QUERYNOTIFICATION_TIMEOUT
Jeśli SQL_SOPT_SS_QUERYNOTIFICATION_MSGTEXT i SQL_SOPT_SS_QUERYNOTIFICATION_OPTIONS nie mają wartości NULL, nagłówek TDS powiadomień o zapytaniach zawierający trzy atrybuty zdefiniowane powyżej zostanie wysłany na serwer przy każdym wykonaniu polecenia. Jeśli jeden z nich ma wartość null, nagłówek nie zostanie wysłany i zostanie zwrócony SQL_SUCCESS_WITH_INFO. Walidacja odbywa się w funkcji SQLPrepare, SqlExecDirecti SqlExecute, z których wszystkie kończą się niepowodzeniem, jeśli atrybuty są nieprawidłowe. Podobnie, gdy te atrybuty powiadomień zapytania są ustawione dla wersji programu SQL Server przed programem SQL Server 2005 (9.x), wykonanie kończy się niepowodzeniem z SQL_SUCCESS_WITH_INFO.
Nuta
Instrukcje przygotowywania nigdy nie spowodują zainicjowania subskrypcji; subskrypcja może być inicjowana przez wykonanie instrukcji.
Przypadki specjalne i ograniczenia
Następujące typy danych nie są obsługiwane w przypadku powiadomień:
tekst
ntext
obrazu
Jeśli zostanie wykonane żądanie powiadomienia dla zapytania zwracającego dowolny z tych typów, powiadomienie zostanie natychmiast wyzwolone, określając, że subskrypcja powiadomień nie była możliwa.
Jeśli żądanie subskrypcji jest wykonywane dla partii lub procedury składowanej, dla każdej instrukcji wykonywanej w partii lub procedurze składowanej jest wykonywane oddzielne żądanie subskrypcji. Instrukcje EXECUTE nie zarejestrują powiadomienia, ale wyśle żądanie powiadomienia do wykonanego polecenia. Jeśli jest to partia, kontekst zostanie zastosowany do wykonanych instrukcji i mają zastosowanie te same reguły opisane powyżej.
Przesłanie zapytania dotyczącego powiadomienia przesłanego przez tego samego użytkownika w tym samym kontekście bazy danych i ma ten sam szablon, te same wartości parametrów, ten sam identyfikator powiadomienia i tę samą lokalizację dostarczania istniejącej aktywnej subskrypcji, spowoduje odnowienie istniejącej subskrypcji, zresetowanie nowego określonego limitu czasu. Oznacza to, że w przypadku żądania powiadomienia dla identycznych zapytań zostanie wysłane tylko jedno powiadomienie. Dotyczyłoby to zapytania zduplikowanego w partii lub zapytania w procedurze składowanej, która była wywoływana wiele razy.