Praca z kwerendy powiadomień
Kwerendy powiadomień wprowadzono w SQL Server 2005 i SQL Server Macierzysta klient. Zbudowany na infrastrukturę usługa Broker wprowadzone w SQL Server 2005, powiadomień kwerendy umożliwia aplikacji, aby otrzymywać powiadomienie, gdy dane zostały zmienione. Ta funkcja jest szczególnie użyteczne w przypadku aplikacji, które zapewniają pamięci podręcznej informacje z bazy danych, takich jak aplikację sieci Web i muszą być powiadamiany, gdy dane źródłowe są zmieniane.
Kwerendy powiadomienie umożliwiają zażądać powiadomienie w ciągu określonego limitu czas zmiany danych źródłowych kwerendy.Żądanie powiadomienie Określa opcje powiadomienie, które zawierają nazwę usługa, tekst komunikatu i wartość limitu czas na serwerze.Powiadomienia są dostarczane za pośrednictwem kolejki usługa Broker, które aplikacje mogą sprawdzają, czy dla dostępnych powiadomień.
Składnia ciąg kwerendy powiadomień opcji jest następująca:
service=<service-name>[;(local database=<database> | broker instance=<broker instance>)]
Na przykład:
service=mySSBService;local database=mydb
Powiadomienie subskrypcja outlive proces, który inicjuje je, jak aplikacja może utworzyć subskrypcję powiadomień i następnie zakończyć.Zachowuje ważność subskrypcja, a powiadomienie będzie występować, jeżeli określone zmiany danych w ramach limitu czas podczas tworzenia subskrypcja.powiadomienie są identyfikowane przez kwerenda wykonana, opcje powiadomienie i tekst wiadomości i może być anulowana przez ustawienie jej wartość limitu czas na zero.
Powiadomienia są wysyłane tylko raz.Do ciągłego powiadomienia o zmianie danych należy utworzyć nową subskrypcję przez re-executing kwerendy po każde powiadomienie jest przetwarzana.
SQL Server Native Client applications typically receive notifications by using the Transact-SQLRECEIVE command to read notifications from the queue associated with the service specified in the notification options.
Uwaga
tabela nazwy musi być kwalifikowany w kwerendach, dla których powiadomienie jest to konieczne, na przykład dbo.myTable. Nazwy tabel musi być kwalifikowany z dwóch części nazwy.Subskrypcja jest nieprawidłowy, jeśli są używane nazwy part trzech lub czterech.
Infrastruktura powiadomienie jest wbudowana w górnej części kolejkowania funkcji wprowadzonych w SQL Server 2005. Ogólnie rzecz biorąc powiadomienia generowanych na serwerze są wysyłane za pośrednictwem kolejki te mają być przetwarzane później.Aby uzyskać więcej informacji na temat SQL Server obsługuje kwerendy powiadomień, zobacz Za pomocą kwerendy powiadomień.
Aby użyć kwerendy powiadomień do kolejki i usługa musi istnieć na serwerze.Te mogą być utworzone przy użyciu Transact-SQL podobny do następującego:
CREATE QUEUE myQueue
CREATE SERVICE myService ON QUEUE myQueue
([https://schemas.microsoft.com/SQL/Notifications/PostQueryNotification])
Uwaga
usługa muszą używać wstępnie zdefiniowanych kontrakt https://schemas.microsoft.com/SQL/Notifications/PostQueryNotification jak pokazano powyżej.
Dostawca OLE DB programu SQL Server Native Client
The SQL Server Native klient OLE DB dostawca supports consumer powiadomienie on zestaw wierszy modification. Konsument odbierze powiadomienie na każdym etapie modyfikacji zestawu zestaw wierszy oraz na wszelkie próby zmiany.
Uwaga
Przekazywanie do serwera z kwerendy powiadomień ICommand::wykonać jest jedynym prawidłowym sposobem subskrybować powiadomienia kwerendy z SQL Server Macierzystego dostawca klient OLE DB.
Do zestaw właściwość DBPROPSET_SQLSERVERROWSET
W celu obsługi powiadomień kwerendy za pomocą OLE DB, SQL Server Macierzysta klient dodaje następujące nowe właściwość do zestaw właściwość DBPROPSET_SQLSERVERROWSET.
Imię i nazwisko |
Typ |
Description |
|---|---|---|
SSPROP_QP_NOTIFICATION_TIMEOUT |
VT_UI4 |
Liczba sekund, czyli pozostają aktywne powiadomienie kwerendy. Wartość domyślna to 432000 sekund (5 dni).Minimalna wartość wynosi 1 sekundę, a wartość maksymalna jest 2 ^ 31-1 sekundy. |
SSPROP_QP_NOTIFICATION_MSGTEXT |
VT_BSTR |
Tekst wiadomości powiadomienie.Jest zdefiniowane przez użytkownika, a nie wstępnie zdefiniowany format. Domyślnie ciąg jest pusty.Można określić wiadomości przy użyciu 1-2000 znaków. |
SSPROP_QP_NOTIFICATION_OPTIONS |
VT_BSTR |
Opcje powiadomienie kwerendy.Określono w ciąg z Nazwa=wartość składni.Użytkownik jest odpowiedzialny za tworzenie usługa i odczytywania powiadomień z kolejki. Wartością domyślną jest ciąg pusty. |
Subskrypcja powiadomienie dba zawsze, niezależnie od czy instrukcja został uruchomiony w transakcji użytkownika lub automatycznego zatwierdzanie lub czy transakcji, w którym został uruchomiony w instrukcji przekazana lub wycofana.Powiadomienie serwera uruchomieniu na jeden z następujących warunków nieprawidłowy powiadomienia: Zmienianie danych podstawowych lub schematu lub po przekroczeniu limitu czasu; zależnie od tego, który jest pierwszy. Rejestracje powiadomienie są usuwane tak szybko, jak ich uruchomienia.W związku z tym po otrzymaniu powiadomienia, aplikacja musi subskrybować ponownie przypadek, gdy chcą uzyskać dalsze aktualizacje.
Inne połączenie lub wątek, można sprawdzić kolejkę docelową dla powiadomień.Na przykład:
WAITFOR (RECEIVE * FROM MyQueue); // Where MyQueue is the queue name.
Należy zauważyć, że SELECT * nie usunięcia wpisu z kolejki, jednak RECEIVE * FROM wykonuje.Zatrzymuje wątek serwera, jeśli kolejka jest pusta.Jeśli istnieją zapisy kolejki na czas rozmowy, są zwracane natychmiast; w przeciwnym razie wywołanie czeka, aż nastąpi zapis kolejki.
RECEIVE * FROM MyQueue
Ta instrukcja natychmiast zwraca zestaw wyników puste, jeśli kolejka jest pusta; w przeciwnym wypadku zwraca wszystkie powiadomienia kolejki.
Jeśli SSPROP_QP_NOTIFICATION_MSGTEXT i SSPROP_QP_NOTIFICATION_OPTIONS są inne niż NULL i nie jest pusta, powiadomienia kwerendy nagłówka TDS, zawierająca trzy właściwości zdefiniowanych powyżej są wysyłane do serwera przy każdym wykonanie polecenia.Jeśli jeden z nich ma wartość null (lub puste), nie jest wysyłana w nagłówku i powstaje DB_E_ERRORSOCCURRED (lub DB_S_ERRORSOCCURRED Jeśli właściwości są oznaczone jako opcjonalne), a wartość stanu zestaw do DBPROPSTATUS_BADVALUE.Sprawdzanie poprawności jest wykonać na przygotowanie/wykonać.Podobnie, DB_S_ERRORSOCCURED jest wywoływane, gdy są właściwości kwerendy powiadomienie zestaw połączeń SQL Server wersje przed SQL Server 2005. Wartość stanu jest w tym przypadek DBPROPSTATUS_NOTSUPPORTED.
Inicjowanie subskrypcja nie gwarantuje zostanie pomyślnie dostarczona kolejnych wiadomości.Ponadto wyboru nie jest wykonywana co do poprawności podanej nazwy usługa.
Uwaga
Przygotowanie instrukcja nigdy nie będzie powodować subskrypcja, było inicjowane; będzie to osiągnąć tylko wykonanie instrukcja i kwerendy powiadomień nie są zagrożeni przy użyciu podstawowych usług baz danych OLE.
Aby uzyskać więcej informacji na temat DBPROPSET_SQLSERVERROWSET zestaw właściwość Zobacz Właściwości zestawu zestaw wierszy i zachowania.
Program SQL Server macierzysty sterownik ODBC klient
The SQL Server Native klient ODBC driver supports query notifications through the addition of three new attributes to the SQLGetStmtAttr and SQLSetStmtAttr functions:
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 jest NULL, zawierającego trzy atrybuty zdefiniowane powyżej nagłówka TDS kwerendy powiadomień zostanie przesłane do serwera za każdym razem, polecenie jest wykonywane.Jeśli jeden z nich jest null, nie jest wysyłana w nagłówku, a SQL_SUCCESS_WITH_INFO jest zwracany.Sprawdzanie poprawności jest wykonywane na SQLPrepare, SqlExecDirect, and SqlExecute, z których się niepowodzeniem, jeżeli atrybuty nie są prawidłowe.Podobnie, kiedy te atrybuty powiadomienie kwerendy są ustawione dla SQL Server wersje przed SQL Server 2005, wykonanie polecenia nie powiedzie się z SQL_SUCCESS_WITH_INFO.
Uwaga
Przygotowanie instrukcja nigdy nie spowoduje, że subskrypcja, było inicjowane; subskrypcji mogą być inicjowane przez wykonanie instrukcja.
Specjalne przypadki i ograniczenia
Następujące typy danych nie są obsługiwane dla powiadomień:
text
ntext
image
Jeśli dla kwerendy, która zwraca jeden z tych typów zostanie zgłoszone żądanie powiadomienia, powiadomienie natychmiast, uruchomieniu Określanie subskrypcja powiadomienie nie było możliwe.
Jeżeli do partia lub procedura przechowywana zostanie zgłoszone żądanie subskrypcja, dla każdego sprawozdania wykonywane w ramach programu wsadowego lub procedura przechowywana zostanie zgłoszone żądanie oddzielne subskrypcja.Instrukcji wykonać nie zarejestruje powiadomienie, ale wysyła żądanie powiadomienie wykonane polecenie.Jeśli jest to partia, kontekście będą stosowane do uruchomionych instrukcji i zastosować te same reguły opisane powyżej.
Przedłożenie kwerendy powiadomienie, który został przesłany przez samego użytkownika w tym samym kontekście bazy danych i ma tego samego szablonu, te same wartości parametrów, ten sam identyfikator powiadomienie i tej samej lokalizacji dostarczania z istniejącej subskrypcja aktywne, odnowi istniejących subskrypcja, resetowanie nowych określonego limitu czas.Oznacza to, że jeśli powiadomienia wymagana jest dla kwerend identyczne, tylko jedno powiadomienie zostanie wysłane.Czy ta dotyczy kwerendy zduplikowane w partia lub kwerendę w procedurze przechowywanej, która została wywołana wiele razy.
See Also