Hallo Robert
Robert Großkopf schrieb:
Hallo Ernst, hallo Andreas,
mit den Jahreszahlen gibt es natürlich keine Probleme, wenn die Datenbank
explizit diesen Datentyp besitzt (ist bei MySQL der Fall nicht aber bei
HSQLDB). Bei MySQL könnte dann die zweistellige Angabe ausreichen. Das würde
übersetzt in 1970-2069.
Da es das bei HSQLDB nicht gibt
( http://hsqldb.org/doc/guide/ch09.html )
sehe ich keine Chance, so etwas im Datenbankentwurf zu erledigen. Ich wüsste
nicht, wie ich ein Minimum und ein Maximum entsprechend für ein Tabellenfeld
im Entwurf vordefiniere - lasse mich aber gerne eines Besseren belehren.
Ich gehe davon aus, dass ich diese Sache nicht mit dem Datenbankentwurf
erledigen kann sondern die Eingabe im Formular beeinflussen muss. Das
bedeutet entweder eine Beschränkung im Eingabeformular ( Das geht ja bei
numerischen Feldern ganz passabel - zwingt allerdings die benutzende Person
bei Fehleingaben zu der Geduld, wirklich alles 4-stellig zu schreiben.) oder
aber mittels eines zweistelligen Feldes und anschließender Auswertung
desselben mit einem Makro und schreiben des entsprechenden vierstelligen
Wertes in die Tabelle.
IMHO siehst Du das richtig. Es gibt aber ein "Gegenbeispiel": Access
kennt im DB-Entwurf unter "Feldeigenschaften" die Eigenschaft
"Gültigkeitsregel". Hier kannst Du sehr elegant eine Bedingung
formulieren; so würde etwa "> 1900 UND <= 2100" in einem als Ganzzahl
deklarierten Feld "Jahr" bei einer Eingabe eben diese auf die beiden
Grenzen 1900 bzw. 2100 testen und mithin nur Jahrzahlen des 20. und 21.
Jahrhunderts zulassen. In einem separaten Feld kann man eine Meldung
hinterlegen, die erscheint, wenn der Benutzer eine falsche Dateneingabe
macht - also genau so, wie man es in Calc handhaben kann: Daten -
Gültigkeit ... Interessanterweise scheint der gleiche Ansatz in Base -
wo er wesentlich nützlicher wäre - nicht implementiert zu sein, oder ich
habe was übersehen. Nur in Formularfeldern ist sowas möglich - was
allerdings wiederum für Formulare und gegen eine Direkteingabe in die
Tabelle spricht 8-) .
Wie Du richtig schreibst gibt es mehrere Lösungsmöglichkeiten - hängt
wie immer von den Vorlieben und - v.a.! - vom Können des Entwicklers ab,
was er schliesslich benutzt.
Ich halte im übrigen die Sache mit der zweistelligen Jahrzahl und der
"automatischen Übersetzung" in eine vierstellige Jahrzahl, wie Du sie
eingangs erwähnst, für eine sehr gefährliche Angelegenheit. Genau diese
Konvention hat uns den Y2k-Bug bzw. das Y2k-Problem beschert, und damit
einige schlaflose Nächte und Zitterpartien für CIO und andere
Verantwortliche. Während man damals als Ursprung noch Speicherknappheit
begründet ins Feld führen konnte, sollte man heute Jahrzahlen schlicht
und ergreifend vierstellig eingeben und speichern: Speicher it zu billig
geworden, um nochmals eine Zitterpartie zu riskieren.
Freundlich grüsst
Ernst
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org
For additional commands, e-mail: users-h...@de.openoffice.org
