Tach!
Und in welcher Datenhaltung speicherst du die Rechnungsdaten inklusive der Rechnungsnummer ab?
Die Daten werden in die Rechnung geschrieben und dann wir ein pdf daraus erzeugt.
Das ist keine Datenhaltung, das ist nur Datenverarbeitung mit anschließendem Verwurf. Es bleibt nur das PDF erhalten und das ist keine brauchbare Datenquelle für weitere Prozesse. "Datenhaltung" ist ein Notieren der Daten im Rohformat zum späteren Wiederverwenden.
Was willst du mit der Anzahl der Klicks? Wenn ich dreimal draufklicke und erst beim vierten Mal deine Validitätsprüfung die Rechnung als einwandfrei weiterverarbeitet ist deine fortlaufende Nummerierung anhand der Klicks unbrauchbar.
Das ist wohl richtig, aber da ich die Rechnung verwende, dürfte das kein Problem sein. Ansonsten kann ich bei einem Klick zu viel auch mal die Nummer ändern wenns sein muss.
Wenn du sowieso aufpassen willst/musst, kannst du auch gleich selbst die Nummer aus dem letzten erzeugten PDF (oder einem Ausdruck) nehmen und eine neue zu Fuß generieren.
Gut, wenn ich denn eine DB verwende, dann habe ich die Kundendaten auch gleich zur Hand. Daraus könnte ich dann die Kundennummer verwenden, okay. Ich werde mir mal SQLite ansehen, danke.
Beachte, dass, wenn du es richtig machen willst, das Prinzip SELECT MAX(Rechnungsnummer)->Increment->INSERT auch bei einer DB nicht mehrbenutzersicher ist. Während User 2 gerade dabei ist, zu Inkrementieren und aus den restlichen Daten das INSERT-Statement zu erzeugen, kann User 1 damit bereits fertig sein und sein INSERT ausführen. Anschließend führt User 2 sein INSERT aus und du hast du zweimal dieselbe Nummer in der Tabelle stehen. Der Zufall wird vielleicht bei dir nie solch eine Situation ergeben, aber wenn doch, so wirst vermutlich du es nicht bemerken sondern erst der Steuerprüfer. Die einfachste Schutzmaßnahme gegen einen solchen Fall wäre ein Unique-Index auf dem Rechnungsnummernfeld. Dann misslingt das INSERT von User 2 und du kannst den Vorgang wiederholen oder vom Anwender wiederholen lassen.
dedlfix.