Verhindern von leeren Datensätzen
Wenn ein User einen neuen Datensatz anlegen möchte und er vor der Erfassung der Daten bzw. der Pflichtfelder prozessual unterbrochen wird, wird dennoch ein neuer - leerer Datensatz angelegt. Wie kann ich dies verhindern?
10 Antworten
-
Hallo Yvonne, das lässt sich prinzipiell gar nicht verhindern. Es wird sofort immer ein neuer, zunächst halt leerer Datensatz erzeugt. Der kann nur gelöscht werden (was bspw. bei Rechnungen natürlich ungünstig ist, weil die Record-Nr. fehlt).
Man kann höchstens eine Formularseite mit den wichtigsten Feldern temporär vorschalten, um dann erst beim Klick auf einen Button per Script den Datensatz in der eigentlichen Tabelle zu erstellen, die bereits erfassten Daten zu übertragen und zur weiteren Bearbeitung zu öffnen.
-
... oder man lässt den User nicht auf "neuen Datensatz erstellen" drücken (deaktiviert diesen Button ggf. sogar über ein Formelfeld und CSS) sondern erzeugt den neuen Datensatz über einen Button (wie planox schon schrieb) und öffnet diese leeren Datensatz gleich via popupRecord() ... wenn dann eine Unterbrechung stattfindet, sieht der User zumindest, dass schon ein neuer Datensatz erzeugt wurde
-
oder bei verlassen der Registerkarte, delete(this) wenn pflichtfelder leer sind
-
Stellt sich zunächst immer die Frage, warum leere Datensätze ein Problem sind. Rechnungsnummern oder ähnliches auf der Record-Id aufzubauen ist generell keine gute Idee.
Für das Folgende gehe ich davon aus, dass leere Sätze einfach "unschön" sind, aber kein Problem darstellen. Ich baue in meinen Programmen diese Konzepte ein:
1. Eine dialog Abfrage sinngemäß ("Möchtest Du wirklich einen neuen Satz anlegen"), die auf einem Button liegt. Der User kann den neuen Datensatz nur darüber anlegen.
2. Die oben bereits erwähnte Formularmaske, die die Daten nach Plausi prüft und den neuen Datensatz erst anlegt, wenn alles komplett ist. Das ist recht aufwändig. Die Maske muss User spezifisch aus einer eigenen Tabelle kommen, damit sich die User nicht gegenseitig die Daten überschreiben. Funktioniert am Besten und hat den Charme, dass der "angefangene" Datensatz user spezifisch zwischengespeichert wird und der User an der selben Stelle weitermachen kann
3. Ein "Verwerfen" button: Ein J/N Feld steuert den Button, nach Eingabe des Datensatzes, solange unvollständig (oder PlausiPrüfung negativ) ist der Buttin sichtbar und löscht den Datensatz auf Druck. Nach vollständiger Eingabe verschwindet der Button. Ich verwende für die DatenAdministration dazu ein weiteres StausFeld, in dem ich den Plausi-Prüf Status festhalte, somit kann ich notfalls manuell löschen.
Die drei Konzepte wende ich nicht unbedingt gleichzeitig an, sondern wähle das jeweils passende. Die Zeiterfassung nutzt z.B. #2, Bei Angeboten nehmen ich 1+3.
Gruß
John
-
ZitronenKiller said:
Stellt sich zunächst immer die Frage, warum leere Datensätze ein Problem sind.Sehe ich genauso. Einzige Ausnahme: Rechnungen. Aber nicht, weil die Rechnungsnummer auf der Record-ID aufgebaut wäre (in der Tat keine gute Idee), sondern weil anhand der nicht manipulierbaren Record-ID bewiesen werden kann, dass keine Rechnungen gelöscht wurden, was ein gewichtiges Argument im Hinblick auf die DSGVO sein kann.
Ansonsten finde ich es auch nicht tragisch, wenn ab und zu versehentlich ein leerer Datensatz erzeugt wird. Zu nBereinigung kann man sich bspw. einen Adminbereich einrichten, in dem man sich regelmäßig alle leeren Datensätze anzeigen lässt und diese nach einer Überprüfung auch per Button löschen kann.
Content aside
- vor 7 MonatenZuletzt aktiv
- 10Antworten
- 360Ansichten
-
8
Folge bereits