Office: AC 2002, Eingabewerte über Kreuz berechnen

Hallo,

angenommen, ich habe zwei Eingabefelder, eins für Zoll und eins für mm. Wie kann ich machen, dass bei der Eingabe enes Wertes in das eine Fenster der Wert für das andere berschnet wird, wobe entweder Zoll oder mm eingegeben werden können und beide Werte dann in die Datenbank kommen?

Gruß,

Steffen.

 

Wäre zwar möglich, aber wenig sinnvoll. Man hätte schließlich eine monströse Tabelle, in der alle Float-Zahlen von 10^-38 bis 10^38 (oder so) in zwei Feldern aufgelistet wären, jeweils mit Faktor 25,4 verknüpft, womöglich noch mehrfach. Das Zeitalter der Tabellenwerke ist vorbei, der Computer heißt so, weil er rechnen kann.

Sinnvoller wäre eine Tabellenansicht, a.k.a. view in einem form mit einem Umrechnungsbutton oder einem zusätzlichen Feld, das den jeweils anderen Zahlenwert anzeigt. Wenn also in der Tabelle die inches angelegt sind, die mm oder so. Das ist im übrigen auch durch eine Abfrage auf die zugrundeliegende Tabelle herstellbar (SELECT MM, MM/25.4 AS INCH, ..., FROM LAENGENTABELLE...) Und wenn der Nutzer eine neue Zahl eingibt, soll er halt eine Option wählen, ob mm oder inch. Ein bißchen Makro- oder VBA-Code dahinter ist jedenfalls ressourcenschonender als so ein redundanter Stiefel.

 

Howdi ho,

die Sache ist, dass manche Werte in inch und manche in mm sind, teilweise sogar in einem Datensatz. Ist sowas wie Bauteile-Klassifikation und ich will ein paar wichtige Masse mit eingeben, nach denen dann gesucht werden kann. Brauche also beide spalten. Kann ja den Zahlenwert auf 8 Stellen beschränken, das reicht dicke, auch für die wilden Zollwerte.

Gruß,

Steffen.

 

Da scheinen Konflikte zwischen Ein/Ausgabe und Struktur unvermeidlich, die die Gefahr der Inkonsistenz bergen: Nehmen wir an, ein record laute
name: "diameter"
mm: 25.4
inch: 1.00

Was will man jetzt? Will man diesen record nur angezeigt haben, ist alles okay.
Aber will man, wenn mm geändert wird (z.b. von 25.4 auf 25.401), den inch-Wert überschrieben haben und vice versa?
Oder will man letztern beibehalten?
oder soll der Datenerfasser beide unabhängig voneinander ändern können?

Gewollt ist vermutlich, daß, wenn auch nur einer angerührt wird, der jeweils andere konsistent dazu sich ändert (und solange gesperrt wird). Damit handelt es sich gar nicht um zwei unabhängige Felder, sondern um zwei Darstellungen ein und desselben Sachverhalts. Anders als Währungen, deren Relationsschwankungen einige Leute reich machen (und andere arm) unterliegt er keinem Wechsel.

Die gängige Methode ist daher, eine Maßzahl und die zugehörige Maßeinheit zu speichern, wobei letztere einer Auswahlliste ("mm", "Zoll", "Yard", "nautical mile", "Werst", ..) entnommen werden kann (und die jeweils andere Maßzahl in einem andern Fenster anzuzeigen, wenn's denn sein muß - aber nicht zu speichern). Dann wird immer die zuletzt eingegebene Zahl und die ihr zugeordnete Maßeinheit gespeichert anstelle zweier Zahlen mit den ganzen Problemen, die die NULL-Wert-Behandlung oder zwei nicht zusammenpassende Zahlen bei Datenimporten und anderem verursachen.
Obiger record hieße dann
name: "diameter"
value: 25.401
unit: "mm"

und zwar unabhängig davon, in wievielen Fensterchen wieviele Längenmaße angezeigt werden, weil das alleinige front-end-Sache ist, bestenfalls noch die Sache einer view.
Natürlich ist niemand gehindert, doch das erste Beispiel zu realisieren, und vielleicht ist jemand von den "Moderatoren" auch willens, die Makros oder Masken dafür schneller als ich zu codieren.
Es geht in meinen Ausführungen auch nicht vordringlich um ein paar zusätzliche bytes auf der Festplatte oder Stromersparnis, weil der Rechner nicht umrechnen muß, sondern um "Design". Das hat weniger mit dem mehr oder minder schönen Aussehen der forms zu tun sondern mit folgerichtigem Denken vor Anlage einer DaBa.

Natürlich kann es auch sein, daß es zu ernstzunehmenden Performanceproblemen kommt, wenn nicht jedes denkbare Maß tabellarisch gespeichert wird. Aber danach sieht es zunächst nicht aus.

 

Hm, einfacher ist sicher, beide Werte zu speichern, die Datenbank ist ja nur da, um vorandene Sachen zu archivieren, soll nicht mehr geändert werden. Eleganter ist sicher, nur einen Wert zu speichern, aber dann muß ja sowohl Eingabe als auch jede abfrage (Filter oder Bericht) die Umrechnung erledigen, klingt nach einigem Programmieraufwand....