Hallo,
ich hab da mal ne Frage:
Ich habe beispielsweise eine Tabelle mit Zahl1, Zahl2 und Ergebnis. Jetzt geb ich im Formular in Zahl1 und Zahl2 etwas ein und lasse diese beiden Multiplizieren und in Ergebnis ausgeben. Jetzt steht das zwar im Formular drinn, aber er speichert das Ergebnis nicht ab. Schau ich in die Tabelle rein, so ist Ergebnis noch immer 0.
Wie bekomm ich das hin das eine berechnung gespeichert wird?
Fragt,
der Daniel
Hi Daniel,
Dumme Frage: Hast du auch das Textfeld im Formular mit der Datenherkunft des Feldes (Ergebnis) deiner Tabelle verknüpft?
Wenn ja, versuch mal, das Formular zu schließen, vieleicht wird es dann zurückgeschrieben.
Wenn gar nichts mehr geht, mußt du das ganze über einen Recordset lösen, aber das ist ein bischen umständlich für so ein bischen…
Vielleicht belehrt uns ja noch jemand, wenn es bei dir nicht klappt.
bis dann,
Jan
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Daniel,
ganz einfach.
Du schreibst in Dein Ergebnisfeld bei Steuerelementeinhalt (ist in den Eigenschaften) die Formel.
=[Zahl1]*[Zahl]
Gruß
Uli
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Daniel,
ganz einfach.
Du schreibst in Dein Ergebnisfeld bei Steuerelementeinhalt
(ist in den Eigenschaften) die Formel.
=[Zahl1]*[Zahl]
Hallo,
ja da hab ich ja auch gemacht. Im Formular bekomm ich das Ergebnis ja auch angezeigt, aber er schreibt es nicht in die DB rein. Lass ich mir die Tabelle auflisten sind die Ergebnis Werte 0.
Noch einen Tip?
Viele Grüße,
Daniel.
Hallo Daniel
Logisch, das kann ja so nicht funktionieren. In Deinem Ergebnisfeld muß natürlich in Steuerelementinhalt der Name des Feldes stehen, in dem der Wert gespeichert werden soll.
Die Berechnung kannst Du z.B. „Beim Verlassen“ des „Zahl2“-Feldes ausführen lassen. Schreibe dazu folgenden Code:
Private Sub Zahl2_Exit(Cancel As Integer)
[Ergebnisfeld]=[Zahl1]*[Zahl2]
End Sub
Gruß
Uli
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Ich frage mich immer, warum man Werte, die man jederzeit (z.B. per berechnetem Feld in einer Abfrage) errechnen kann, in Tabellen speichert. Entspricht doch irgendwie nicht den datenbanktechnischen Grundsätzen, oder?
Gruß
SW
Stimmt schon, aber dieser Wert ist unter umständen ein anderer als der, der errechnet wird. Im Grunde soll bei mir ein Preis errechnet werden. Dieser wird aber manchmal ‚manuell‘ geändert wenn es rabatte oder sowas gibt, da müßte dieser Wert wieder konstant sein.
Ich bin kein DB Experte und da es auch eine kleinere DB bleiben wird mach ich mir jetzt auch nicht die Arbeit alles genau zu optimieren oder gar in die dritte normalform bringen. Die zweite hat gelangt 
Gruß,
Daniel
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Private Sub Zahl2_Exit(Cancel As Integer)
[Ergebnisfeld]=[Zahl1]*[Zahl2]
End Sub
Dankeschön, ich werds probieren.
Grüße,
Daniel
Na ja, wenn man nachträglich was verändern will, kann man doch den betreffenden Satz editieren und z.B. in einem Feld
Rabatt (in der Tabelle tatsächlich gespeichert) einen anderen Prozentsatz eingeben, sodaß sich bei erneutem Aufruf einer
Abfrage (oder anderer Aktualisierungsmethoden) in einem dort befindlichen berechneten Feld wieder entsprechend aktualisierte Werte befinden (hinsichtlich Preisberechnung). Also wenn ich in einem Fall einen bestimmten Mehrwertsteuersatz zugrunde liegen habe, speichere ich diesen mit dem entsprechenden Artikeldetaildatensatz ab (oder übergeordnetem Rechnungsdatensatz, je nach Anlage-Philosophie der ganzen Geschichte). Die Postensumme (und irgendwann dann auch der Rechnungsbruttobetrag) errechnet sich doch dementsprechend. Wenn ich jetzt auf die Idee käme, einer bereits erstellten Rechnung (bzw. einem in früherer Vergangenheit errechnetem Preis) nachträglich (warum auch immer) nun einen gesonderten Rabatt einräumen zu müssen, wäre buchhalterisch sauber die Lösung die, dieser Rechnung (eindeutig identifiziert über ihre RGID) eine Gutschrift einzuräumen in einer gesonderten Tabelle (und schon wieder ganz klassisch: 1 Rechnung kann wiederum n-beliebig viele
Gutschriften haben) - das Ganze in 'ner entsprechenden Abfrage gegenübergestellt, ergibt doch wieder ganz korrekte
Ergebisse. (Übrigens dürfen Rechnungen nicht nachträglich betragsmäßig verändert werden, sondern erfordern einen
entsprechenden dokumentierbaren Datensatz, der die Rabattierung/Stornierung oder was auch immer ausgibt.
Normalisierung:
Wenn die zweite schon so anstrengend war: auch kleine Projekte wachsen und dann hat man den Salat. Glaub’ mir’s.
Überhaupt ist Normalisierung (ob von 1-5 ist egal) kein Hexenwerk - wenn man mit gesundem Verstand schlicht und
ergreifend dafür sorgt, daß jedes Tabellenattribut immer nur von einem eindeutigen Schlüssel abhängt, ist man schon auf der
sicheren Seite. Alles andere ist was für die Informatik-Freggles an den Hochschulen.
Gruß
SW