|
| |
Fragen & Antworten rund um sev-Komponenten| 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 |
 |
|
sevISDN 1.0 
Überwachung aller eingehender Anrufe!
Die DLL erkennt alle über die CAPI-Schnittstelle eingehenden Anrufe und teilt Ihnen sogar mit, aus welchem Ortsbereich der Anruf stammt. Weitere Highlights: Online-Rufident, Erkennung der Anrufbehandlung u.v.m. Weitere InfosTipp des Monats Neu! sevDTA 3.0 Pro 
SEPA mit Kontonummernprüfung
Erstellen von SEPA-Dateien mit integriertem BIC-Verzeichnis und Konto- nummern-Prüfverfahren, so dass ungültige Bankdaten bereits im Vorfeld ermittelt werden können. Weitere Infos
|
| |
|
Copyright ©2000-2024 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.
Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel
|
|
Mai 2024
Sie sind aktuell nicht angemeldet.
