Locking: sinnvolle Strategie

[af0815]

AUTSCH!!
OK, bin ich noch nicht mit konfrontiert worden.

That's why I'm asking here ggg

Bei MS-SQL sind durch die Treiberschicht (FreeTDS meistens) einige Sachen besonders die StoredProcedures nicht besonders gut anzusprechen (Erfahrung mit SQLdb). Da gibt es massive Einschränkungen mit Rückgabewerten etc. Auch multiple Resordsets werden IMHO nicht unterstützt.

Nachdem ich für Linux programmieren musste/durfte, konnte ich natürlich nicht auf ZEOS und dort ADO als Treiberschicht ausweichen. Überhaupt habe ich da wenig aktuelles Wissen, wie ZEOS (vielleicht besser) damit umgeht. Für Spezialfragen ZEOS betreffend kann ich nur auf das dortige Forum verweisen, das sehr rasch und kompetent antwortet. Wenn man echt Probleme mit Englisch hat, einfach das ganze dort dual (1x durch google translate) posten, etliche dort sind deutschsprachig

Vielleicht auch noch ein kleiner Hinweis zu MS-SQL. Der Server läuft auch unter spezifizierten Linux-Versionen sehr gut und auch in der 'freien' Version mit den entsprechenden Einschränkungen. Absolut stabil (jahrelang produktiv im EInsatz) und lässt sich mit den wirklich exzellenten SQL-Tools von M$ hervorragend bedienen und warten. Vor allen sind die Debugging und Informationstools ein echter Hammer (ja, ich habe einige M$-Schulungen durchlaufen, also kenne ich doch einiges von der Pike auf, deswegen auch MS-SQL geschädigt ).

[charlytango]

"ID .. irgend eine Art des Prim Keys (vielleicht autoincrement)" --> Definitiv nicht Auto-Increment.
Eher im Sinne von:
Tabellen-Name||ID-Des-Satzes||Was-sonst-Noch

Weil nur OHNE AutoIncrement kannst du in die Situation kommen, dass ein Primärschlüssel-Wert bereits in der Tabelle ist, als solches auch erkannt wird, falls User 2 versucht, denselben Satz zu ändern

Einigen wir uns doch bitte auf ein paar Begrifflichkeiten sonst denken wir aneinander vorbei, was bei euch hier schade wäre, denn ich will ja aure grauen Zellen anzapfen

Ich nenne das logische Konglomerat (zB ein Kontaktfenster einer Person) das aus mehreren Tabellen besteht einmal das Sperrobjekt.

Die Tabelle die das leisten soll ist

TLocking
*************
LockingID .. irgend eine Art des Prim Keys (vielleicht autoincrement)
UserID .. user der sperrt
LockingTheme ... ZB "K" für Kontakte, "F" für Faktura
SperrObjektID ... die zum Sperrobjekt gehörende Prim ID zB einer Person.
LockingTimeStamp .. Wann wurde der Lock eingetragen

LockingType ... experimentel, ich denke an "read" oder "edit"
(vermutlich ist das ohnedies schon obsolet)

irgendetwas ähnliches wie das

Code: Alles auswählen

BEGIN TRANSACTION; 
-- Attempt to acquire the lock by updating the control row 
INSERT into TLocking (UserID,LockingTheme,SperrObjektID)
Values(4711,“K“,<PersID aus der Kontaktetabelle>)
WHERE NOT EXISTS  etc etc

-- Check if the lock was acquired (1 row affected)
IF @@ROWCOUNT = 1
BEGIN
    COMMIT;
END
ELSE
BEGIN
    -- Lock was not acquired, rollback
    ROLLBACK;
    RAISERROR ('Could not acquire lock. Another user holds the lock.', 16, 1);
END
END TRANSACTION;

[Joh]

Also ich bin eindeutiger Verfechter davon, einzelne Datensätze zu sperren.
Früher habe ich die Sperre einfach beim Ersten editieren gesetzt, heute bin ich dafür, das der Benutzer erst per Auswahl in den Editiermodus gehen muß.
Aber das ist eher meinem Tremor-Kunden geschuldet: irgendwo reingeklickt, irgendwas reingeschrieben, dann gespeichert...


Es stellt sich für mich erstmal die Frage, wie viele User sind betroffen.
Wer editiert was.
Hier schwirrte was von 10 Usern durch den Raum.

Meine Frau würde sagen: lass doch mal die Kirche im Dorf.

Bei 10 Benutzern kenne ich das so:
- Ein paar schreiben Angebote
- Eine/r schreibt Rechnungen
- Eine/r editiert Kunden
- Eine/r editiert Artikel

Kunde 0815 Meyer wird nur von Frau Witt bearbeitet.
Und wenn der Verkäufer doch einen Kunden anlegt, wird dieser Kunde von keinem anderen bearbeitet werden.
Wenn tatsächlich mal 2 Benutzer den gleichen Datensatz bearbeiten wollen: solange die Meldung eindeutig ist, wird der Vorgang zur Seite gelegt und später bearbeitet.
Der Lagerfuzzi liest eh nur und schreibt Listen.

Bei einem Record-Locking kommt sich da eigentlich keiner in die Quere.
Nur weil ich Mittags Kunden Meyer gelockt habe, will
i) kein weiterer dort editieren
ii) wenn doch, heißt es spätestens beim zweiten Mal: wenn du in die Pause gehst: schließ den Vorgang ab.

Auf dem Lager darf auch keiner den einzigen Gabelstapler damit blockieren, das er die Würstchendosen einzeln ins Regal räumt: 6 Lagen à 12 Kartons à 12 Dosen.