Office: (Office 2010) Autragsnr. & Änderung eines Auftrags bei mehreren Nutzern

Hallo,

ein Freund hat mich gebeten, eine Access-Datenbank für seine kleine Firma zu erstellen. Auf die Datenbank sollen vier Nutzer über ein Netzwerk zugreifen können. An sich ist die Aufgabe relativ leicht, ich mache mir nur etwas wegen den folgenden zwei Punkten sorgen:

-Eine Tabelle enthält alle Aufträge, wobei ein Auftrag eine laufende Nummer hat. Angenommen User A möchte einen neuen Auftrag anlegen und öffnet nun das entsprechende Formular. User B möchte auch einen Auftrag anlegen und öffnet wenig später ebenfalls das entsprechende Formular.
Es ist naheliegend, so etwas wie MAX(AuftragsNr)+1 nicht beim Öffnen des Formulars auszuführen, denn man hätte zwei Aufträge mit der gleichen Auftragsnr (wobei das Speichern daran scheitern dürfte, weil das der Primary Key ist).
So etwas wie MAX(AuftragsNr)+1 sollte man also meiner Meinung nach kurz vorm Speichern (=Anlegen des Datensatzes) machen, zumal eine Auftragsnr nicht für die chronologische Reihenfolge der Aufträge stehen muss. Dennoch muss wohl eine Sperrung der gesamten Tabelle her, bevor abgespeichert wird. Oder sehe ich das falsch?
-Es soll auch die Möglichkeit geben, einen bestehenden Auftrag zu ändern, z.B. wenn sich die Uhrzeit der Abholung ändert. Angenommen zwei User bearbeiten gleichzeitig einen Datensatz. A möchte die Uhrzeit der Abholung ändern und B möchte die Uhrzeit der Zustellung ändern. Dann gibt es eine Konfliktgefahr. An sich reicht es meiner Meinung nach, wenn man nur den Datensatz sperrt...?

Ich habe bzgl. Konflikten in DBSMs nur theoretisches Wissen aus einer DBSII-Vorlesung und bitte deshalb um Hilfe. *wink.gif*

Vielen Dank!

Gruß,
Diego

:)

 

Die Nummer sollte nur bei einem neuen Datensatz berechnet und vergeben werden: Im Form_BeforeUpdate ...
Code:

Bei einem etwas intensiveren Mehrnutzerbetrieb muss man noch etwas mehr Aufwand betreiben.

Zweite Frage: Im Formular in den Eigenschaften Sperrung des bearbeiteten Datensatzes einstellen.

 

Bei einem etwas intensiveren Mehrnutzerbetrieb muss man noch etwas mehr Aufwand betreiben.

Danke für die Antwort, Eberhard.
Eine Frage zum 1. Punkt: Heißt das man kommt ohne Sperren aus? Dein Vorschlag deckt aber nicht den Fall ab, dass zwei User gleichzeitig einen Datensatz anlegen, oder (auch wenn dieser Fall sehr unwahrscheinlich ist)?

Gruß,
Diego

 

Sperrungen werden vorhandene Datensätze (Editierungen) betreffen, neu angelegte Datensätze sind ein anderes Thema.

Bei einem neuen Datensatz weiß das Backend noch nichts von Inhalten, die vielleicht von mehreren Seiten gleichzeitig und damit konflikterzeugend erzeugt werden, sondern nur, dass ein neuer Datensatz angelegt und schon mal ein automatischer Primarkey reserviert/vergeben wird. Vewrschiedene User werden aber verschiedene neue Datensätze anlegen.
Konflikte treten dann erst nach dem Abspeichern auf, wenn welche erzeugt wurden.

 

Mal die Probe aufs Exempel, ob ich es richtig verstanden habe: Da die AuftragsNr der Primary Key ist, braucht man kein Sperren beim Anlegen eines Datensatzes?

 

Ein Primärschlüssel ist eindeutig. Beim zweiten Speichernversuch des gleichen Schlüssels gibt es einen Schlüsselfehler und damit keine Speicherung des Duplikats.

 

Hallo Diego25!

Ein etwas anderer Gedanke:

Jeder Anwender legt einen neuen Auftrag zunächst in einer Tabelle seines FEs an.
Diese Tabelle ist genau so aufgebaut wie jene des BEs, nur ohne ID (und Auftragsnummer). Auch mit denselben Abhängigkeiten und Beziehungen.
Erst beim Speichern erhält dieser Datensatz eine ID (und Auftragsnummer) gemäß BE. Wer zuerst speichert "gewinnt" die nächste ID.
Bei einem neuen Auftrag einander in die Quere kommen können sich Anwender dann nie.

Sperrungen beim Ändern vorhandener Datensätze sind, wie Eberhard schon schrieb, ein anderes aber nicht wirklich ein Problem.

Wolfgang

 

Hallo zusammen,

Danke erstmal für die Antworten.

Ich denke die Aufteilung in ein Front- und Backend macht nur dann Sinn, wenn man z.B. nicht möchte, dass User X die Tabelle Y lesen/manipulieren darf (wenn etwa die Informationen vertraulich sind). Wenn aber alle User gleichberechtigt sind, macht die Aufteilung nur dann Sinn, wenn man möchte, dass User nur über Formulare mit der Datenbank interagieren und so nichts kaputtmachen können.
(Ich habe bisher nie eine Aufteilung gemacht, von daher diese kurze Zusammenfassung, um zu sehen, ob ich den Sinn richtig verstanden habe.)

@Wolfgang: Das mit der Tabelle im FE verstehe ich nicht. Tabellen sind doch bei einer Aufteilung nur Bestandteil des BEs, nicht aber des FEs?

Gruß,
Diego

 

Hallo,
die Aufteilung einer Datenbank hat mit Vertraulichkeit nichts zu tun. Auch wenn die DB aufgeteilt ist, hast Du das gleiche Problem. Die Tabellen sind ja eingebunden und so für jeden erreichbar, wenn nicht im Rahmen der (beschränkten) Möglichkeiten von Access Gegenmaßnahmen getroffen werden. Da gibt es keinen Unterschied ob aufgeteilt oder nicht. Trotzdem, sollte im Mehrbenutzerbetrieb eine DB geteilt sein (völlig unabhängig von Vertraulichkeitsbetrachtungen). Auch mit Formularen hat das nichts zu tun. Du kannst auch mit einer aufgeteilten DB ohne Formulare arbeiten, was man aber nicht tun sollte.
Das Backend kommt auf den Server und jeder User bekommt sein eigenes Frontend. Wenn jetzt die DB (die Useroberfläche) weiterentwickelt wird und sich an der Tabellenstruktur nichts geändert hat, kann man einfach das FE austauschen und hat trotzdem die zwischenzeitlich im BE neuen/geänderten Daten.

 

\@Diego: Diese Gedanken sind nun alle unzutreffend. Inhalte einer verknüpften Tabelle kann man ebenso gut manipulieren wie die von internen Tabellen. Diese Sicherheit gewinnt man nicht.

Man gewinnt aber Anwendungssicherheit und Stabilität, wenn jeder User sein eigenes Frontend hat. Z.B. wäre eine Mehrfachnutzung einer globalen Variable sehr problematisch.

Die Trennung in FE und BE ist auch aus Entwicklersicht sehr sinnvoll. Der Entwickler kann die Entwicklung (überwiegend am FE) in aller Ruhe in seiner eigenen Umgebung vornehmen, dort genügt ein strukturgleiches Backend mit ausreichenden Testdaten. Mit einer weiteren Entwicklungs- und Pflegestufe wird dann das FE beim Anwender ersetzt, die Daten im Backend müssen da nicht angefasst oder gar umgeschichtet werden.

 

Danke für die Infos.

Ist diese Aufteilung auch am Ende möglich oder muss man bereits zu Beginn einer neuen Datenbank die Aufteilung machen?

 

Hallo,
diese Aufteilung kannst Du auch nachträglich machen. Da gibt es (zumindest bis Access2003) einen Assistenten dazu.
Wo der sich aber bei Access2010 versteckt (wenn es den noch gibt), kann ich Dir mangels Access2010 aber nicht sagen.

 

Hallo Diego25!

In einem FE sind Tabellen sehr wohl sinnvoll.
Natürlich nur dann, wenn jeder Anwender sein eigenes FE hat.
Was auch immer sein sollte.
ZB. persönliche Einstellungen, die das Design der Formulare betreffen.
Temporäre Tabellen, die durch Auswertungen des Anwenders erzeugt werden. Aber auch in dem von mir beschriebenen Fall.
Wobei die hier Engagierten sicher noch weitere Möglichkeiten sehen dürften.

Wolfgang

 

Warum eigentlich kein Autowert?

 

Also die Auftragsnummer muss wie ich inzwischen erfahren habe einem bestimmten Schema entsprechen, d.h. laufende Nr/Monat/Jahr wobei die laufende Nummer beim Jahreswechsel zurückgesetzt wird. Beispielsweise wäre eine Auftragsnummer die 845/11/14, d.h. Auftrag 845 im November des Jahres 2014.

Ich habe dafür schon eine Idee wie ich das umsetze, hänge aber gerade an anderer Stelle etwas. Laut SQL Data Types for Various DBs gibt es in MS Access anders als in MySQL keinen Datentyp ENUM(x,y,z,etc.). Nun ist es so, dass es je nach Auftrag 1-3 Ladeorte geben kann und sehr selten auch einen vierten. Eine Möglichkeit wären also vier Attribute, d.h. Ladeort1, ..., Ladeort 4. In MySQL wäre hierfür wohl der ENUM-Typ geeignet, auch wenn man dann vermutlich gegen die 1NF verstoßen würde.
Was sagt ihr dazu?