Office: (Office 2010) Eindeutige Satznummer generieren

Ich bin glaube ich nun auf die Lösung gestossen, zumindest werde ich das testen. Das - hoffentliche - zauberwort heisst adlocckpessimistic.

Hilfstabelle mit einem Satz, in dem die nächste frei Nummer steht.

Beim drücken des Buttons "Speichern" nach der Erfassung eines Auftrages wird die Hilfstabelle in VBA geöffnet, ein select mit adlockpessimistic, übernahme der Nummer ins Formular, erhöhen der Nummer, update (und Aufhebung des Locks), close der Tabelle.

Versucht ein zweiter Benutzer zu lesen, sollte er nach meienr Erwartung eine Systemmeldung Satz gesperrt bekommen. Er kann dann den Button nochmal drücken und alles ist gut. Laufen beide Speichern Aktionen nacheinander gibt es eh keine Probleme.

Ich werde berichten.

 

Mag situationsbezogen ein "nice-to-have" Punkt sein.
Mir wäre allerdings kein wirklicher Grund bekannt, wo man eine durchlaufende Nummerierung haben muss solange die Nummerierungen eindeutig sind.
Selbst bei Rechnungsnummern ist das nicht mehr notwendig.

 

\@racoon sorry über manche Dinge möchte ich nicht diskutieren.
Ich suche ganz einfach: Lösungen.
Ich bin Laufende Nummern ohne Lücken aus meinem Tagesgeschäft gewohnt. Da habe ich aber andere Werkzeuge. Deshalb war die einzige Frage: Geht das unter Access? Inzwischen habe ich aus den Antworten herausgelesen - Im Prinzip Nein. Wie gesagt werde ich nun das adLockPessimistic probieren. Wenn es klappt sind alle meine Probleme gelöst.

 

Geht mir nicht um Diskussionen, sondern um ein Beispiel für einen zweckmässigen Einsatz! Vielleicht komme ich ja mal in die Verlegenheit, in der sowas benötigt wird...
Nur wie gesagt.... in den vergangenen 25 Jahren ist mir das nicht einmal passiert und deshalb sehe ich darin keinerlei Sinn! Verstehen würde ich es aber schon gern.
Nur wenn du deine Gründe nicht nennen magst.... ok!
Gehen tut das unter Access schon. In einer Multi-User-Umgebung kannst du es aber programmiertechnisch nicht immer sicherstellen. Nach X funktionierenden Vorgängen wird es immer mal einen Fall geben, der dir eine Lücke verursacht. Und diese Lücke liesse sich beim nächsten Vorgang gleicher Art dann schliessen. (Gibt diverse Threads im Netz zu Quasi-Laufende-Nr/Quasi-Auto-Wert und dergleichen, in denen sowas nachgestellt wird. Ob das bei deinem Vorhaben passt, lässt sich mangels Auskunft nicht sagen. Also bitte selbst probieren.)

 

...und ein Feld für diese NR in der Tabelle (eindeutiger Index) und eine Anfügeabfrage
die diese Nr erweitert?

Denke, wenn diese Nr in der gleichen ""Sek einfügt wird, wird eine "Fehlermeldung" starten.
Die man wiederum abfangen kann, wenn das ganze in eine Funktion abgehandelt wird und dennoch diese, dann wieder neue Nr vergeben kann.

Aber, das wirst wohl auch nicht diskutieren wollen *Smilie

Guten Tag

 

Hallo!

@Kyron9000:
Der Feuerwolf redet nicht mit jedem hier im Forum.
Geschweige diskutieren.

Wolfgang

 

Ich werde nun das mit adlocckpessimistic testen.

Das ist vom Aufwand her minimal und sollte mich zum Ziel führen. Wenn nicht ..... muss ich zusammen mit Cheffe überlegen was wir machen.

 

Hallo @Wolfgang,

das habe ich schon bemerkt und mir auch gemerkt *Smilie

PS: für was fragt er dann... um eine punkt-passende Antwort zu bekommen?! *Smilie

 

Hallo,
und das Forum hat er auch gewechselt, sind aber die gleichen Antworten.

halte ich alles für überflüssig. Eindeutiger Index und Max+1 reicht.

 

Hallo!

Ich bin auch der Meinung, dass ein eindeutiger Index inkl. Max(..)+1 beim Einfügen ausreicht.
Lücken können nur entstehen, wenn Datensätze gelöscht werden. (Das müsste in dieser Tabelle verboten werden.)
Im Ausnahmefall (bei exakt gleichzeitigem Einfügen) kann es höchstens zu einer Schlüsselverletzung kommen. Dann startet man einfach den Einfügevorgang erneut und alles ist wie es sein soll.


Da Access 2010 zum Einsatz kommt, würde ich das außerdem nicht über Client-Code lösen sondern einen Trigger (Datenmakro) dafür verwenden.


mfg
Josef

 

\@gpswanderer ..... ob überflüssig oder nicht meine Frage war einfach gibt es sowas wie "adlocckpessimistic" gibt und wie sie sieht die Syntax in einem VBA-SQL aus.

@josef, da ich keine Lücken will, ist sichergestellt, dass in der Anwendung keine Datensätze gelöscht werden. Es gibt eine Status gelöscht bzw zurückgenommen.

 

Du kannst die Hilfstabelle mit dem Zählerstand einfach für das Schreiben sperren. ADO Recordset -> Option -> dbDenyWrite. Den Zähler erhöhen und die Tabelle wieder freigeben. F1 kann grundsätzlich helfen. *Smilie

Hilfstabelle ist natürlich nicht nötig. Einfacher wäre natürlich: einfach die Datentabelle öffnen und über die Anzahl der Datensätze der Zähler generieren.

 

Hilfstabelle ist natürlich nicht nötig. Einfacher wäre natürlich: einfach die Datentabelle öffnen und über die Anzahl der Datensätze der Zähler generieren.

 

Nun ja, es gibt Ecken und Kanten. Eigentlich: "Der Kopf ist rund, damit das Denken die Richtunbg wechseln kann."

Die oben genannten einfachen Methoden sind durchaus geeignet, eine durchgehende laufende Nummerierung zu erzeugen.

Das Sperren einer Tabelle hat doch eher den Hintergrund, im Mehrnutzerbetrieb eine mehrfache Verwendung der gleichen Nummer wegen der zeitgleichen Ermittllung (Zeit von Errechnung bis Speicherung) zu verhindern. Das ist offensichtlich ein anderes Thema, auch wenn beides eng zusammenhängen kann.

Vielleicht wäre es zielführend, Aufgaben klar zu benennen und danach eine Diskussion zu führen.

 

Hallo!

Wo ist der Vorteil bei der Sperre im Vergleich zu einer PK-Schlüsselverletzung beim Speichern?

Wenn ein Client den Datensatz sperrt, kann ein anderer nichts damit machen => es kommt zu einem Fehler, der abgefangen werden muss.
Wenn ein Client und ein anderer (rein theoretisch) zur gleichen Zeit eine Anfüge-Abfrage mit em identischen PK-Wert abschicken erhält einer einen Fehler wegen Schlüsselverletzung => dieser Fehler muss abgefangen werden.

Welchen Vorteil hat die Sperre der Tabelle? - Ich sehe da eher Nachteile, nämlich für jene User, die bereits vorhandene Datensätze ändern wollen.

mfg
Josef