Zitat von
Generalissimo:
@Robert_G: Vielleicht verstehen wir uns falsch, aber gehst du davon aus die ganze Zeit ne Transaktion offen zu halten??
Jupp, wir haben uns falsch verstanden.
Ein Alert flag würde niemals abgeschickt werden, wenn die Transaktion nicht mit einem Commit abgeschlossen wird.
Von Table locking auf record ebene halte ich persönlich nicht viel.
Selbst wenn sich mehrere Sessions mit alert flags oder pipes zuschieben, ist die allgemeine Performance WESENTLICH höher als bei ständiger Prüfung, ob ein Record gesperrt wurde oder nicht.
Nachtrag:
Zitat von
Peter Geyer:
Der Käsemann
Sorry, das war
absolut nicht böse gemeint.
Zitat von
Bernhard:
Sperren auf
DB-Ebene ist immer Schlecht, da vor allem beim MS-
SQL-Server u.U. auch reine Lese-Abfragen gesperrt werden.
Das sehe ich ganz anders. Ich finde das sämtliche Logik, die in der
DB realisiert werden kann, auch genau dorthin gehört.
Dein
DCOM- Server klingt verdammt interessant, dürfte aber
IMHO für wesentlich mehr Roundtrips sorgen als eine Kommunikation auf
DB-Ebene.
Im neuen Entwickler gibt es einen Artikel über eMail-Benachrichtigungen bei betimmten Events auf dem
SQL Svr. -> Es _MUSS_ also auch dort eine Möglichkeit zur sessionübergreifenden Kommunikation geben. (MS ist sowieso schon seit langem dabei sämtliche fancy Features von Oracle für ihren Spross zu kopieren.
)
Über die Sinnlosigkeit des Sperrens bei einem SELECT habe ich mich, glaube ich, schon in einem anderen Thread ausgelassen.
Nachtrag:
Wenn man sämtliche Logik vom
DB-Server auslegern würde, wären Datenbanken wie der
SQL Svr, Oracle, Caché oder PosGreSQL (BTW die ist ein genialer Geheimtipp für alle Geizhälse mit dem Anspruch auf eine "richtige"
DB) witzlos und wir könnten alle mit "Billigkram" wie
mySQL,
Paradox, MS Jet und Konsorten arbeiten.
Zitat von
Peter Geyer:
Ich fürchte nämlich das die Kommunikation zwischen den Sessions wirklich ein Krampf werden.
Das glaube ich nicht.
Ich weiß nicht wie es bei euch "
SQL Svr"'lern implementiert ist. Aber ich denke es ist auch dort möglich sich für eine Art Event/Benachrichtigung oder sonstwas zu registrieren.
Wenn es kein Gegnstück zu Oracle's RowID gibt, musst du fix die PrimKeys der Tabelle in den Trigger schreiben (oder eine SP basteln, die das für dich erledigt
).
Ansonsten hast du dann pro Tabelle einfach einen Trigger der Before Update, Before Insert und Before Delete feuert. Er muss dir jetzt nur den Schlüssel des DS liefern (wenn es keine Gegenstück zur RowID gibt, auch den Tabellennamen). Eine Möglichkeit, wie du im Programm darauf reagieren kannst, habe ich dir weiter oben schon vorgeschlagen.
Das Ganze wird in ein paar Stunden Bastelei und theorie ausarten, aber das Ergebnis wäre eine Chance, dieses Problem elegant, ohne Zusatzserver zu umschiffen. (Bei mir klappt es einwandfrei, sogar bei "bösen" Bulk DML Statements mit 5-stelligen DS-Zahlen)