MS SQL und Events

[Peter A. Smolik]

Hallo,

Ich hab ein sehr großes Datenbankprojekt das ich in Punkto Geschwindigkeit verbessern möchte.
Ein großes Problem stellt dabei die laufende Aktualisierung dar.
In meinen Interbase-Projekten arbeite da immer mit Events um nicht ständig die Querys neu zu öffnen sondern nur dann wenn sich wirklich was an den Daten geändert hat. Das funktioniert da eigentlich super gut. Nun nicht jeder will sich mit einer Interbase Datenbank anfreunden bzw. hat schon einen MS-SQL Server im Haus. Ich such jetzt nach einer Möglichkeit das auf einem MS-SQL Server genauso zu machen, werde aber einfach nicht fündig.
Hat schon mal jemand mit Events auf einem MS SQL Server zu tun gehabt?

Für jeden Tipp dankbar

Euer
Peter

[Andreas Kosch]

Hallo,

ein direktes Gegenstück zu den InterBase-Events gibt es beim MS SQL Server nicht. Man muss sich zwischen zwei Alternativen entscheiden: <br>
a) Microsoft SQL Server Notification Services <br>
b) Aufruf von COM-Objekten aus T-SQL heraus

Der erste Weg wird in dem Papier <i>http://www.microsoft.com/sql/techinfo/development/2000/sqlnsto.asp</i> näher beschrieben. Der zweite Weg (MS SQL Server ruft ein mit Delphi geschriebener Client "zurückgerufen") ist hier im FORUM über die Suche nach der Zeichenkette <b>sp_OACreate</b> in Form eines Beispiels zu finden

[Peter A. Smolik]

Danke,

Es bestätigt sich mal wieder das es die wirklich perfekte Datenbank noch immer nicht gibt. Denn jede hat irgendwo ein Manko. Bei InterBase fehlt die Volltext Engine und die AutoIncrement, und die Boolschen Feldtypen. Bei MS eben die Events.
Ich hab mir mal beides angesehen. Stellt sich jetzt die Frage was die bessere Methode bei MS SQL ist? Denn ich will ja damit erreichen das das Netzwerk entlastet wird aber auch der Client nicht an Performance verliert.
Welche würden Sie bevorzugen Herr Kosch?

mfg
Pete

[Andreas Kosch]

Hallo,

&gt;Welche würden Sie bevorzugen

keine von beiden - denn der in der Aufrufhäufigkeit nicht vorhersehbare "Callback" vom Server zum Client ist genau so "schädlich" wie das ständige Pollen der Clients. Was passiert, wenn einer der Clients den Netzwerkstecker zieht oder sonst aus irgend einem Grund (Bsp: CPU-Last 100%) nicht fristgerecht antwortet?

Wenn es sich nicht vermeiden lässt und der Client tatsächlich ständig aktuelle Daten anzeigen muss, greife ich auf das regelmässige Pollen (d.h. neue Transaktion, SELECT-Abfrage neu ausführen) zurück. Nur so geht man kein Risiko ein, den SQL-Server durch ein Client-Problem lahmzulegen.

Etwas anderes ist es, wenn die Benachrichtigung des Clients durch den SQL Server relativ selten vorkommt - in diesem Fall ist das Risko deutlich kleiner, so dass man sich darauf einlassen kann