Guten Tag,
wie kann ich in base in der Tabelle direkt aus den Feldern “Gebühr” und “bezahlt” im nächsten Feld “offen” den Wert berechnen lassen?
Danke im Voraus für Eure Hilfe
Also ich bin wahrlich kein Datenbanker, aber ein so ein Ansinnen in der Datenbank berechnete/abgeleitete Größen in separate Felder einzufügen kommt mir immer ein wenig wie “Spreadsheet-Denke” vor. Meines Erachtens ist sowas das Ergebnis von Abfragen.
Du hast natürlich recht, Opaque.
In ACCESS soll das funktionieren. Ich selbst brauche das nicht.
Ein Vereinsmitglied hatte mich danach gefragt und ob ich bei der Gelegenheit Daten aus SPI OA IV rüberholen kann, welches ich in den Jahren 1964-1986 programmiert hatte. Das sind 33 Jahre her, manche stellen sich das so einfach vor.
Danke trotzdem für deine schnelle Antwort.
Also, das ist schon sinnvoll in bestimmten Zusammenhängen. So ein ‘berechnetes Feld’ ist eigentlich kein Feld, sondern ein online gerechneter Wert, der wie ein Feld dargestellt und genutzt werden kann. Nehmen wir mal das Beispiel. Irgendwo in der Programmlogik wird aus ‘Gebühr’ und ‘bezahlt’ ein ‘offen’ berechnet und fix in das dafür vorgesehene echte Feld geschrieben. Dann kann man ab da nicht mehr sicher davon ausgehen, dass in ‘offen’ wirklich immer der richtige Wert steht, wenn die Programmlogik nicht vorher sicherstellt, dass das gerade frisch berechnet wurde. Und da liegt dann eben der Sinn eines solchen berechneten Feldes, dass zwangsläufig immer den gültigen Wert zur Verfügung stellt.
Wie man unten sieht ( @Ratslinger ), geht es mit Firebird. Auch Access (ab 2010) kennt solche ‘Felder’. Ob das auch mit der hsqldb geht (von der ich ausgehend von Deinen anderen Posts ausgehe), müsste jemand anderer beantworten. So weit habe ich mit base noch nicht auseinandergesetzt.
@Cookievore - Wie gesagt, ich bin kein Datenbanker und verstehe daher auch Dein Beispiel/Deine Erläuterung nicht. Wenn es aber in Datenbanken implementiert wird, scheint es dafür auch Gründe (ich vermag mir nur Perfomance-Gründe vorzustellen) zu geben, sowas zu tun.
@anon73440385 , ja, Performance ist eine Überlegung dabei. Vorteil, weil es entgegen einer Berechnung in einer Abfrage oder in einem Formular nicht bei jeder Ausführung erneut gerechnet wird (also schneller ist) und ein Nachteil, weil die Tabelle doch zumindest prüfen muss, ob das berechnete Feld zu aktualisieren ist (also langsamer ist, als eine Tabelle ohne berechnete Felder). Gretchenfrage ist also ob die db-Engine im Hintergrund oder die Programmlogik zum Anzeigezeitpunkt rechnen soll. Wahrscheinlich ist das hier ob der Anzahl Datensätze aber nicht entscheidend.
Anzeige von wie auch immer gearteten Status-Informationen auf einer Datenzeile beschreibt den Sinn vllt. am besten.
@Schwebebahn hat an anderer Stelle schon etwas über sein Vorhaben einer Art Mitgliedsbeitrags-OP-Liste gepostet. Es blieb aber offen, ob der von ihm eingeschlagene Weg zu seinem gewünschten Ziel führen könnte.
Mit der eingebetteten Firebird-Datenbank können Sie mithilfe von SQL eine Tabelle erstellen, die ein berechnetes Feld enthält
Beispiel-SQL (weitere Informationen finden Sie in der Firebird-Dokumentation):
CREATE TABLE SALARY_HISTORY
(
EMP_NO SMALLINT NOT NULL PRIMARY KEY,
CHANGE_DATE TIMESTAMP DEFAULT 'NOW' NOT NULL,
UPDATER_ID VARCHAR(20) NOT NULL,
OLD_SALARY NUMERIC(10,2) DEFAULT 0 NOT NULL,
PERCENT_CHANGE DOUBLE PRECISION DEFAULT 0 NOT NULL,
NEW_SALARY COMPUTED BY (old_salary + old_salary * percent_change / 100)
);
erstellt erfolgreich Tabelle & berechnetes Feld.
Das obige Beispiel wurde aus der Firebird Server-Beispieldatenbank bezogen und in Firebird Embedded getestet.
Danke euch allen für eure Hilfe.
Der Kasswart, dem ich LO näher bringen wollte, will weiter auf Papier schreiben, es ist ihm alles zu kompliziert. Gut, er ist 81. Für mich (76) sage ich ehrlich, ist Firebird noch zu kompliziert Die HSQLDB ist durchschaubar. Sollen die Verantwortlichen des Vereins sehen, wie sie ggf. weiter kommen.
Ich jedenfalls, kann mit der HSQLDB das alles machen, was iich benötige.