Sinnvollstes Sperrkonzept in folgender Situation...
-
Muss auf einer Clientdatenbank wie Access ebenso laufen wie unter SQL-Server
Beim SQL-Server sollte sich das Problem von alleine Lösen, wenn du
alles in eine Transaktion packst
die Bedingungen ("kann ich den Eintrag machen ohne dass Unsinn rauskommt") in der Transaktion verifizierst, bevor du Änderungen machst
einen passenden TRANSACTION ISOLATION LEVEL (ala SERIALIZABLE) verwendestIIRC lockt SQL Server dann alles, was er braucht, um die diversen Ergebnisse für Abfragen in der Transaktion zu bestimmen. Soll heissen: wenn du ein "WHERE a = 5 AND b BETWEEN x AND y" in einer Abfrage hast, dann wird SQL-Server entweder selbst einen TABLE LOCK holen, oder aber einen passenden INDEX LOCK, falls ein passender Index vorhanden ist (was er dann sein sollte).
Natürlich solltest du das ganze nochmal anhand der Doku und mit ein paar Tests verifizieren, denn es kann natürlich sein dass ich da was falsch verstanden oder falsch in Erinnerung habe.
Was Access angeht... keine Ahnung. Vielleicht könnte man bei Access ja auch weiterhin die Table-Lock Variante beibehalten. Access wird im Multi-User Betrieb ja sowieso furchtbar langsam, ist also sowieso nicht wirklich gut für Multi-User Anwendungen geeignet. Vielleicht wäre es also verschmerzbar, da die alte Table-Lock Variante beizubehalten.
-
Für mich hört sich das eher nach Unique Constraints an. So dass man Ressourcen zeitlich verplant und einen eindeutigen Schlüssel über Zeitraum und Ressource legt. Dann muß allerdings eine Zeitraumüberlappungsprüfung erfolgen.
-
@witte
Aber wie soll man diese "Zeitraumüberlappungsprüfung" machen?
Ich wüsste mit SQL Server keine Möglichkeit das gebacken zu bekommen.
Und mit Access schon garnicht.
-
hustbaer schrieb:
Was Access angeht... keine Ahnung. Vielleicht könnte man bei Access ja auch weiterhin die Table-Lock Variante beibehalten.
...die Leider über Komponenten gemacht wird, die ich demnächst entfernen muss...
(Umstellung auf ADO und dort ist das Setzen des Tablelock bei Access nicht möglich)
-
witte schrieb:
Für mich hört sich das eher nach Unique Constraints an. So dass man Ressourcen zeitlich verplant und einen eindeutigen Schlüssel über Zeitraum und Ressource legt. Dann muß allerdings eine Zeitraumüberlappungsprüfung erfolgen.
Da liegst du in der Annahme nicht verkehrt, nur kenne ich keine DB die bei einem Key außer Eindeutigkeit auch ein Bereich unterstützt...
-
Und wenn man dann einen Trigger nimmt der vor dem Einfügen/Aktualisieren die bereits vorhandenen Daten auf Überlappungen prüft? Access kennt keine Trigger, hat aber dennoch Funktionen. Kann man diese zum Aktualisieren aufrufen die die Prüfung vornehmen und im Erfolgsfall den Eintrag vornehmen? Ich weiß nicht ob das geht.
-
asc schrieb:
hustbaer schrieb:
Was Access angeht... keine Ahnung. Vielleicht könnte man bei Access ja auch weiterhin die Table-Lock Variante beibehalten.
...die Leider über Komponenten gemacht wird, die ich demnächst entfernen muss...
(Umstellung auf ADO und dort ist das Setzen des Tablelock bei Access nicht möglich)Bist du sicher dass es in "Jet-SQL" keine Möglichkeit gibt einen Table-Lock zu setzen?
Oder vielleicht könnt ihr den Access-Support ja gleich ganz droppen
-
Also bei INSERT/UPDATE ist das ja alles kein Problem. Verstehe aber die ANforderung noch nicht ganz. Möchtest Du beim SELECT die DAten schon sperren damit kein andere die Daten selektieren kann?
Da ist folgendes Problem: Wieviel Zeit hat der SELECTOR die Daten zu ändern?
Was wenn er in die Mittagspause, Feierabend,Urlaub geht?
Dann darf niemand die Daten selektieren also braucht man eine Freigabe.
Da sollte man eine Zeitrahmen definieren um die Daten freizugeben falls sie nicht verändert wurden. (in MSSQL kein Problem)
RDBMS wurde ja hier nicht gesagt oder?
-
hustbaer schrieb:
Oder vielleicht könnt ihr den Access-Support ja gleich ganz droppen
Dagegen hat mein Chef etwas
Auch wenn ich davon angetan wäre...
-
Unix-Tom schrieb:
Also bei INSERT/UPDATE ist das ja alles kein Problem. Verstehe aber die ANforderung noch nicht ganz. Möchtest Du beim SELECT die DAten schon sperren damit kein andere die Daten selektieren kann?
Da ist folgendes Problem: Wieviel Zeit hat der SELECTOR die Daten zu ändern?
Was wenn er in die Mittagspause, Feierabend,Urlaub geht?
Dann darf niemand die Daten selektieren also braucht man eine Freigabe.
Da sollte man eine Zeitrahmen definieren um die Daten freizugeben falls sie nicht verändert wurden. (in MSSQL kein Problem)
RDBMS wurde ja hier nicht gesagt oder?Die Sperre soll möglichst innerhalb des Speichervorganges gesetzt werden (Wo dann noch über ein Select vorsichtshalber ein Abgleich geschieht). Bislang dauert dieser Vorgang (und das nur auf der größten Datenbank in einem extremen Spezialfall) etwa eine halbe Minute. Sprich: Die Prüfung/Sperrung etc. sollte nicht die Anwendung blockieren wenn einer meint eine Maske in auf alle Ewigkeiten geöffnet zu lassen.
