|
| |
Fragen & Antworten rund um sev-Komponenten| sevDataGrid - Feldprüfung | |  | | Autor: crosstravel | | Datum: 02.02.18 12:16 |
| Hallo,
in einem Grid erfasse ich für eine Reisebuchung die Namen der Teilnehmer. Vor der Anzeige
des Grids werden die vorhandenen Informationen (Namen) bereits abgefüllt und dann angezeigt.
Das sieht dann wie folgt aus:
Name Vorname
Mustermann Eugen
Mustermann Eugen
Hier werden zwei teilnehmer auf die Reise gebucht. da aber nur 1 Name (der Name des Buchers)
bekannt ist, wird dessen Name auch in der 2. Row vorgegeben. Da in einer Buchung nicht zwei
gleiche Namen vorkommen dürfen, müsste der Benutzer einen der Namen ändern. Wenn er aber beim
2. Namen z.B. mit TAB darüber geht, wird AfterCellEdit nicht ausgelöst.
Wie und wo kann ich sicherstellen, dass nicht zwei gleiche Namen innerhalb einer Reisebuchung
in die Tabelle geschrieben werden?
Vielen Dank
Rainer | |
| Re: sevDataGrid - Feldprüfung | | | | Autor: Manfred X | | Datum: 03.02.18 06:50 |
| Hallo!
Dieses Thema berührt meiner Ansicht nach die grundsätzliche Frage der
Benutzerführung.
Wieso werden die Angaben zu der Person, die die Buchung einer Reise vornimmt,
nicht getrennt erfasst von der Liste der (Mit-) Reisenden?
Diese Person fungiert in der Regel als Kontakt, wickelt Zahlungen ab usw.
Es sind deshalb mehr Informationen zu erfassen als bei den Mit-Reisenden.
Grundsätzlich sollte es ein Formular "Buchung" geben, bei dem durch die Betätigung
eines "OK"-Buttons die aktuelle Buchung jeweils abgeschlossen wird.
Im Click-Event dieses Buttons wären alle Angaben zu kontrollieren (Vollständigkeit,
Plausibilität, Datenbank-Abgleiche). | |
| Re: sevDataGrid - Feldprüfung | | | | Autor: Franki | | Datum: 04.02.18 02:05 |
| Hallo Rainer,
auf Namensgleichheit zu prüfen reicht definitiv nicht aus bei gewerblichen Anwendungen, das hatte ich schon in meiner Schulzeit erfahren da es dort 3 bis 4 Schüler mit gleichem Vor- und Nachnamen gab. Ok, ich habe einen Allerweltsnamen der damals halt modern war, aber gut meine Eltern haben das so entschieden...
Du musst für konkrete Identifizierungen von Personen mindestens ein weiteres Merkmal verwenden z.B. Geburtsdatum / Kundennummer / oder was auch immer. Wie und ob das geht hängt auch mit Datenschutz zusammen, aber das ist ja ein anderes Thema.
Denn es kann durchaus bei einer Reisebuchung vorkommen, dass mehrere Personen den gleichen Namen haben. (Klassenfahrten in meiner Schulzeit waren auch so, damals noch keine EU und bei der Grenzkontrolle haben die Beamten uns die falschen Ausweise zurück gegeben, war schon lustig irgendwie)
Gruß Frank (damals moderner Vorname) Müller (Allerweltsname)
Beitrag wurde zuletzt am 04.02.18 um 02:09:47 editiert. | |
| Re: sevDataGrid - Feldprüfung | | | | Autor: crosstravel | | Datum: 04.02.18 05:55 |
| Hallo zusammen,
danke für die Abtworten.Ich habe das problem nun organisatorisch gelöst. Dabei habe ich vor dem Füllen des DataGrids die Namen mit einer Vorgangsnummer ergänzt und geprüft, ob dennoch doppelte namen innerhalb eines Vorganges vorkommen. Ist dies der Fall, wird der Name durch eine weitere, eindeutige Kennung ergänzt.
Schönes Wochenende
Rainer | |
| Re: sevDataGrid - Feldprüfung | | | | Autor: Manfred X | | Datum: 04.02.18 10:25 |
| Hallo!
Eigentlich sollte in einer Datenbank jede Person
- unabhängig davon ob eine Namens-Doppelung vorliegt -
eine eindeutige ID zugewiesen bekommen.
Die Eindeutigkeit darf nicht nur innerhalb eines bestimmten Vorgangs
sicher gestellt werden, sondern muß sich auf den Inhalt der gesamten
Person-Tabelle der DB beziehen.
Anderenfalls wäre die Erfassung individualisierter Daten (Namen etc.)
ohnehin nicht erforderlich und sollte deshalb aus Datenschutzgründen
unterbleiben.
Beitrag wurde zuletzt am 04.02.18 um 10:29:31 editiert. | |
| Re: sevDataGrid - Feldprüfung | | | | Autor: Franki | | Datum: 05.02.18 03:42 |
| Hallo Rainer,
organisatorische Lösungen sind immer gut. Aber deine Lösung empfinde ich nicht optimal.
| Zitat: | |
Dabei habe ich vor dem Füllen des
DataGrids... | |
Ich gehe mal davon aus, dass die Daten in einer Datenbank stehen. Und genau hier solltest du ansezten, d.h. in der DB selbst darf dein Problem gar nicht vor kommen, das muss schon bei der Erfassung der Daten geregelt werden.
| Zitat: | |
die Namen mit einer Vorgangsnummer ergänzt und
geprüft, ob dennoch doppelte namen innerhalb eines Vorganges
vorkommen. Ist dies der Fall, wird der Name durch eine
weitere, eindeutige Kennung ergänzt. | |
Und das machst du bei jedem Datensatz temporär bei der Befüllung des Grids? Das ist Verschwendung von Rechenleistung pur.
Organisatorisch würde ich so vorgehen:
| Zitat: | |
Hier werden zwei teilnehmer auf die Reise gebucht. da aber nur 1 Name (der Name des Buchers)
bekannt ist, wird dessen Name auch in der 2. Row vorgegeben.
| |
Das ist schon falsch und fehleranfällig. Warum nicht die zweite Row leer lassen, der User muss den zweiten Namen des Mitreisenden eigeben. Tut er das nicht, kann der Datensatz nicht gespeichert werden, bzw. der User bekommt den Hinweis, dass er den zweiten Namen eingeben muss. Einfach vorbelegen und übernehmen ist kontraproduktiv denn es relativ selten, dass zwei Reisende den gleichen Namen haben, also warum den gleichen Namen vorbelegen?
Und was machst du wenn mehr als zwei Leute zusammen reisen möchten? Belegst du dann auch alle Felder mit dem gleichen Namen vor?
Wenn X Leute reisen möchten bei der Buchung sind auch X-1 Felder zusätzlich auszufüllen vom User der buchen möchte. Alles andere macht nur Schwierigkeiten und ist auch nicht üblich.
Und wie schon gesagt, selbst wenn der User doppelte Namen eingibt ist das ja nicht schlimm, es gibt Namensgleichheit aber dem Buchenden vergibst du eine ID, bzw. der Buchung selbst die den Vorgang unabhängig vom Namen identifizieren kann in der DB. Und nur dort und nicht erst beim Einlesevorgang in ein Grid.
Gruß
Frani
Schönes Wochenende
Rainer | |
| Re: sevDataGrid - Feldprüfung | | | | Autor: crosstravel | | Datum: 05.02.18 06:30 |
| Hallo zusammen,
ich denke, ich sollte die problematik etwas näher beschreiben. Grundsätzlich ist es so, dass ein Kunde eine Reise, z.B. nach Italien, bucht. Die Buchung kann 1 - n Personen umfassen. Oftmals handelt es sich um Familienmitglieder. Deshalb wird auch jede Folgezeile mit dem Namen des buchers vorbelegt; wohlwissend, dass dann der Vorname geändert werden muss. Jede Buchung wird eindeutig durch eine Buchungsnummer identifiziert. Pro Buchung gibt 2 2 Tabellen.
Die Sitzplatz-Tabelle sieht wie folgt aus:
Record-ID SitzNr Buchung Name
2145 23 1801234 Müller, Frank
2146 24 1801234 Müller, Brigitte
2137 25 1801234 Muster, Hans
Die Teilnehmer-Tabelle stellt sich wie folgt dar:
Record-ID Buchung Name Vorname SitzNr
4578 1801234 Müller Frank 23
4579 1801234 Müller Brigitte 24
4580 1801234 Muster Hans 25
Es kommt öfters vor, dass die Sitzplätze der Kunden nach der Buchung noch geändert werden müssen. Das
betrifft in dem Fall die zwei Tabellen. Das Problem ist nur, dass von den einzelnen Rows der Sitzplatz-
Tabelle kein direkter Bezug zur Teilnehmer-Tabelle hergestellt wird. Deshalb die Krücke über den Namen.
Gruss
Rainer | |
| Re: sevDataGrid - Feldprüfung | | | | Autor: crosstravel | | Datum: 05.02.18 07:38 |
| Ich habe eben gesehen, dass die Darstellung der Beispieltabellen nicht optimal ist. Tut mir leid.
Ich möchte nochmals die Situation erläutern.
Ausgangslage:
-------------
Der Teilnehmer Müller, Frank möchte nicht auf Sitz 23 sitzen, da dieser direkt neben der Tür ist. Der
Aktion
------
Der Sachbearbeiter öffnet des Programm für die Verwaltung des Bussitzplanes der Reise 8es handelt sich um Busreisen) und setzt Müller, Frank auf Platz 30 (wenn dieser frei ist). Das erfolgt in der Sitzplatz-Tabelle. Das ist soweit ok. Jetzt gibt es aber noch die Teilnehmer-Tabelle welche auch die Sitzplatz-Nr
enthält. Auch hier muss diese von 23 auf 30 geändert werden.
Da eine Sitzplatznummer nur 1x in einem Bus vorkommen kann, bietet sich hier dieser Begriff als Kriterium an und auf den Abgleich der Namen kann verzichtet werden.
Mir ist bewiusst, dass das DB-Design vielleicht nicht optimal ist. Es wird wohl in der kommenden Zeit ein Re-Design erforderlich werden.
Gruss
Rainer | |
| Re: sevDataGrid - Feldprüfung | | | | Autor: Franki | | Datum: 06.02.18 03:33 |
| Hallo Rainer,
| Zitat: | |
Oftmals handelt es sich um Familienmitglieder. Deshalb wird auch jede Folgezeile mit dem Namen des buchers vorbelegt; wohlwissend, dass dann der
Vorname geändert werden muss. | |
Hier fängt es schon an, warum nimmst du nicht zwei getrennte Felder für Vornamen und Nachnahmen der Familienmitglieder, den Nachnamen kannst du ja vorbelegen, den Vornamen lässt du leer, den muss der User halt ausfüllen. Und wenn im Formular sowohl Vor- als auch Nachname Pflicht sind kann der User das auch nicht per TAB einfach übergehen. (Wie du das intern in der DB regelst ist eine andere Sache, du kannst beide Daten in ein Feld speichern und sogar per Split wieder auseinander nehmen.
| Zitat: | |
Es kommt öfters vor, dass die Sitzplätze der Kunden nach der
Buchung noch geändert werden müssen. Das
betrifft in dem Fall die zwei Tabellen. Das Problem ist nur,
dass von den einzelnen Rows der Sitzplatz-
Tabelle kein direkter Bezug zur Teilnehmer-Tabelle
hergestellt wird. Deshalb die Krücke über den Namen.
| |
Ok, da weiß ich nicht wie du das machst bei der Erfassung der Buchung. Aber jeder Name des Reisenden sollte ja einen Sitzplatz haben der schon bei der Buchung zugewiesen werden kann durch den User (Sofern frei) Hier sollte dem User bei der Erfassung schon ein Sitzplan angezeigt werden wo er für jedes Familienmitglied seinen Wunschplatz direkt mit angeben kann.
Wenn es dann Änderungen geben soll, kann der User seine Buchung editieren und auch nur zwischen den noch freien Sitzplätzen wählen. Oder aber innerhalb seiner Buchung die Sitzplätze tauschen.
| Zitat: | |
Da eine Sitzplatznummer nur 1x in einem Bus vorkommen kann, bietet sich hier dieser Begriff als Kriterium an und auf den Abgleich der Namen kann verzichtet werden.
| |
Eben nicht, das ist dein Gedankenfehler. Denn auf einem Sitzplatz kann nur eine Person sitzen und genau deren Namen brauchst du. Ob da der Frank, die Brigitte, der Hans oder sonst wer sitzen möchte kannst du nur über eiene eindeutige Identifizierung der Person regeln. Ein Sitzplatz = eine Person, völlig unabhängig vom Namen oder gar der Buchungsnummer.
| Zitat: | |
Mir ist bewiusst, dass das DB-Design vielleicht nicht optimal ist. Es wird wohl in der kommenden Zeit ein Re-Design erforderlich werden.
| |
Ja das scheint mir auch notwendig.
Und hier solltest du nicht nur auf die DB achten sondern auch auf die Eingabefelder die der User hat bei Ersteingabe bzw. bei seinen Änderungswünschen. Das beste DB Design nützt nichts, wenn der User das als nicht komfortabel bei der Eingebe findet.
Also alle eindeutigen Daten zuerst verwalten. Buchungsnummer, Namen, Sitzplätze, Haltestellen auf der Reise falls vorhanden bei Abfahrt und Ankunft am Ziel. Usw. usw.
Danach kommen erst die Tabellen, deren Beziehungen usw. nach Analyse was der User in deiner Software für Möglichkeiten haben soll. Es sind oft auch weitere Kriterien notwendig die eindeutig sein müssen wenn es z.B. bei Preisfindung um Kinder, Senioren, Rabatte, VIP-Kunden usw. geht. Aber da muss jeweils eine Eindeutigkeit hergestellt werden können.
Du kannst dich gerne mal per PM an mich wenden, ich habe Erfahrung in Buchungssystemen für Hotelreservierungen
Gruss
Frank | |
 | Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
 Einloggen | Neu registrieren |
 |
|
sevOutBar 4.0 
Vertikale Menüleisten
á la Outlook
Erstellen von Outlook ähnlichen Benutzer- interfaces - mit beliebig vielen Gruppen und Symboleinträgen. Moderner OfficeXP-Style mit Farbverläufen, Balloon-Tips, u.v.m. Weitere InfosTipp des Monats Access-Tools Vol.1 
Über 400 MByte Inhalt
Mehr als 250 Access-Beispiele, 25 Add-Ins und ActiveX-Komponenten, 16 VB-Projekt inkl. Source, mehr als 320 Tipps & Tricks für Access und VB
Nur 24,95 EURWeitere Infos
|
Mai 2024
Sie sind aktuell nicht angemeldet.