Hallo,
ich hab mal wieder ein kleines Problem, bei dem ich Hilfe gebrauchen könnte!
Ich habe in einem Unterformular Felder angelegt um Werte zu berechnen.
Nun möchte ich in der Fußzeile die einzelnen Summen der berechneten Felder angezeigt bekommen.
Ich erstelle also ein ungebundenes Textfeld und schreibe folgende Formel:
= Summe([berechnetesTextfeld])
Statt mir ein Ergebnis zu liefern, bekomme ich allerdings in jedem berechnetem Feld: #Fehler
Was mache ich falsch?
HAllo,
falsch ist, den Namen des berechnten Feldes als Paramter für die Summen-Funktion einzusetzen. Schreib als Parameter den Berechnungs-Ausdruck (Berechnungsformel) selber hin.
Hallo,
Ich habe nun folgendes gemacht:
- im Unterformular ein Feld GesamtZutat im Fußbereich angelegt.
- dahinter liegt die Formel: =Summe([Zutat])
- im Unterformular habe ich dann ein Feld Prozent angelegt
- dahinter liegt die Formel: =[Zutat]/[Gesamtzutat]
- Funktioniert alles super
Nach der oben auf geführten Lösung habe ich das dann so gemacht:
- im Unterformular ein Feld GesamtProzent im Fußbereich angelegt.
- dahinter liegt die Formel: =Summe([Zutat]/[Gesamtzutat])
- Funktioniert nicht => #Fehler
Was ist daran falsch?
Hallo,
"GesamtZutat" ist doch ein berechnetes Feld, und das wird als Parameter in der Summenfunktion benutzt, was wie gesagt nicht geht....
Aber die Formel: =Summe([Zutat]/Summe([Zutat])) funktioniert auch nicht.
Wie muss ich es denn machen???
Hallo,
sorry, aber was soll =Summe([Zutat]/[Gesamtzutat]), wenn Feld SummeZutat im Feld GesamtZutat berechnet wird?
Und was soll Feld GesamtProzent überhaupt berechnen, außer 100??
Gruß Oma
Also, nochmal ganz auführlich:
Ich benutze Access 2007 um eine Rezepturverwaltung zu erstellen.
Ich habe drei Tabellen angelegt:
- Artikel: ID, Artikel, Lieferant, Kg-Preis
- Rezeptur: ID, Bezeichnung
- Zutat: ID, RezepturID, Zutat, Zutatenmenge
Dann habe ich jeweils eine Abfrage von Artikel und den Zutaten erstellt.
Zum Schluß habe ich dann ein Formblatt Rezeptur erstellt, dazu dann ein Unterformular Zutat (aufgrund der Abfrage)
In dem Unterformular kann ich dann die einzelnen Zutaten und die dazugehörigen Zutatenmengen auswählen bzw. eingeben.
Funktioniert auch alles wunderbar.
Im Formularfuß des Unterformular habe ich mir die Gesamtmenge der Zutaten berechnen lassen. Auch das funktioniert.
Nun möchte ich allerdings die die Rezeptur auf ein Kilo umrechnen (also Zutatenmenge / Summe(Zutatenmenge).
Dann möchte ich natürlich auch den Kilopreis wissen. Also berechnete Kg-Zutatenmenge*Artikelpreis. Das Funktioniert auch soweit. Aber Die Summe des Kilopreises bekomme ich nicht berechnet.
Ich hoffe nun ist es verständlich!
Hallo,
irgengwie noch nicht so ganz.
Es fehlt in Tabelle Zutaten noch eine ArtikelID, wie sonst ist der Zusammenhang zwischen kg_Preis und Zutat erkennbar.
Dann sind sicherlich nicht nur "jeweils eine Abfrage" zu erstellen, sondern auch eine Abfrage , die Artikel und Zutat zusammenführt?.
Und wenn du dann im Unterformular die Zutatenmenge und den zugehörigen Preis hast, dann kannst du doch im Detailbereich des Unterformulars berechnen: =[Zutatenmenge]*[kg_Preis] und im Formularfuß =Summe([Zutatenmenge]*[kg_Preis]
Gruß Oma
Hallo,
meine Verknüpfungen und Abfragen funktionieren.
Ich möchte nur wissen wie man die Summe von berechneten Feldern anzeigen lässt.
Den einen Tipp habe ich nicht umsetzen können (siehe oben).
Gruß
Baluga
Hallo,
das Datenmodell ist so noch nicht richtig, ich halte es sogar für unbrauchbar. Siehe Hinweise von OMA, wie willst Du eine Zuordnung zum Preis haben, wenn es keine Beziehung gibt?
In welchen Zusammenhang steht denn die Artikeltabelle? Die hängt ja einfach in der Luft.
Die problematik fließt doch direkt in die Berechnung ein, die bei korrekten beziehungen einfach in der Abfrage gemacht werden kann.
So wirst Du da nicht viel Glück haben, obwohl die Verknüpfungen und Abfragen funktionieren.
Die Verknüpfungen sind alle vorhanden, habe nicht alles aufgeschrieben, weil ich es nicht für notwendig gehalten habe.
Denn es funktioniert sonst alles einwandfrei.
Ich möchte nur unter meinen berechneten Felder ein Summenfeld.
Hallo,
dann erkläre doch mal den richtigen Aufbau, dann kann man auch einen Vorschlag machen für die Summenbildung.
Es geht ja möglicherweise viel einfacher, wenn man alles kennt.
Kann mir jemand erklären, wie ich hier eine Datei hochladen kann?
Hallo,
dazu musst du angemeldet sein, dann unter mit Erweiterte Optionen...
Gruß Oma
So,
registriert und Datei eingefügt!
Nun hoffe ich, dass mir jemand die leeren Felder füllen kann.
Und wenn wir schon dabei sind, würde mich auch interessieren, ob mein Datenmodel so richtig ist!
Gruß
Baluga
[Anhang gelöscht durch Administrator]
Hallo,
du findest hier mehr Helfer, wenn du die DB nach Access2003 konvertierts, da 2007 noch nicht viele(wie auch ich) benutzen.
Gruß Oma
Hallo,
konvertiere die DB nach Access2003, Access2007 haben noch nicht so viele, ich auch nicht, kann daher die DB nicht öffnen.
Hier die 2003er Version!
[Anhang gelöscht durch Administrator]
Hallo,
das Datenmodell scheint zu stimmen (unter Vorbehalt), allerdings wieso gibt es Bananenkeks in der Rezeptur und als Artikel? Das ist doch unlogisch, für Bananenkekse brauche ich bestimmte Zutaten, aber doch nicht die Bananenkekse selbst, oder? Ich habe Dir mal die Beziehungen auf referentielle Integrität eingestellt und die Datentypen der Beziehungen angepasst.
Weiterhin habe ich die ganzen Nachschlagefelder entfernt, die sollten in Tabellen unter keinen Umständen verwendet werden.
Das Ufo habe ich über die Schlüsselfelder verknüpft, der Formularbezug in der Abfrage ist dann überflüssig.
Die Berechnungen sind mir allerdings völlig unklar. Das Maismehl kostet 1,49€/Kg, 0,25Kg werden verwendet, die kosten dann 0,37€. Wie kommst Du zu 0,78 ?
Zu den Nachschlagefeldern:
ZitatAccess Anfänger: Die Nachteile von Nachschlagefeldern
aus DBWiki, dem Datenbank-Entwickler-Wiki
Man sollte Nachschlagefelder in Tabellen vermeiden, denn
1. Ein Nachschlagefeld verbirgt den eigentlichen Feldinhalt. Wenn man beispielsweise eine Tabelle in Datenblattansicht öffnet, wird ein Firmenname dargestellt, obwohl in Wirklichkeit im Feld die Kundennummer steht, und der Firmenname aus einer anderen Tabelle stammt. Nachschlagefelder verhindern, dass Datenbanken sauber durchstrukturiert angelegt werden.
2. Eine Abfrage, die das Nachschlagefeld verwendet und nach dem dargestellten Wert sortieren soll, funktioniert nicht. So wird im obigen Beispiel nicht nach dem Firmennamen, sondern nach der Kundennummer sortiert. Ebensowenig funktioniert die Angabe des Werts als Kriterium - auch hier müsste man die Nummer anstelle des Namens verwenden, um Ergebnisse zu erhalten. Wenn man den Wert aus einer Wertliste eines Kombinationsfelds auswählt, kann es passieren, dass gültige Daten mit falschen Werten überschrieben werden.
3. Das Nachschlagefeld beinhaltet eine (intern angelegte) Beziehung zwischen den Tabellen sowie die Anlage zusätzlicher Indizes, die in aller Regel überflüssig sind und die Datenbank unnütz aufblähen. Auch kann es vorkommen, dass man auf diese Weise die maximal zugelassene Anzahl von Indizes je Tabelle unwillentlich überschreitet.
4. Ein Kombinationsfeld auf der Basis eines Nachschlagefelds kann bei Filterung des Formulars dazu führen, dass der Filter mit dem Formular gespeichert wird. Beim nächsten Öffnen des Formulars fehlt der Wert und wird nachgefragt, was wiederum zu einem Fehler führt.
5. Berichte, deren Datenherkunft Nachschlagefelder enthält, benötigen Kombinationsfelder zu deren Darstellung, die den Bericht langsam und ineffizient machen können.
6. Die Datenbank kann nicht vernünftig von außen abgefragt (beispielsweise in Form einer Datenquelle eines Word-Serienbriefs) oder exportiert werden, da die Nachschlagefelder nicht nach außen gereicht werden.
7. Wenn man das Access-Sicherheitssystem verwendet, reichen die Berechtigungen oft nicht aus, um die Nachschlagefelder mit Inhalt zu füllen, was zu schwer nachzuvollziehbaren Fehlern führt. Das gilt insbesondere, wenn man aus Sicherheitsgründen mit Abfragen mit "WITH OWNERACCESS OPTION" arbeitet.
DBWIKI ist zur Zeit nicht mehr Online, daher als Zitat.
Anbei mal die DB mit den Korrekturen.
[Anhang gelöscht durch Administrator]
Hallo Baluga,
die üblichen Vorschläge:
1. nicht mit Nachschlagefelder in den Tabellen arbeiten.
2. nicht mit Formularbezüge in Abfragen arbeiten
3. In den Tabellen Primär- und Fremdschlüssel immer als Zahlen (z.B. RezepturID in tabZutat als Zahl u. kein Nachschlagfeld!)
4. Als Datenherkunft besser gespeicherte Abfragen benutzen
Mit 3. ergibt sich dann auch die Beziehung zwischen tabZutat und tabRezeptur mit den Feldern RezepturID
und auch der Formularbezug in qryZutat nicht notwendig.
Zu den Berechnungen: wahrscheinlich deute ich die Felder falsch?
von Maismehl wird im Rezept 0,25 kg verbraucht und der Preis beträgt 0,75 E pro KG. Warum ist nun der Preis nicht =[ZutatMenge]*[Preis] und der Gesamtpreis im Fuß =Summe([Zutatmege]*Preis]) ?
Gruß Oma
@Oma,
auch ich habe ja die Berechnungen nicht verstanden. Aber ich sehe für Maismehl 1,49€/Kg, 0,25 Kg = 0,37€, ausgeweisen sind aber 0,78€
Da sind noch Erläuterungen notwendig.
Hallo Klaus,
jo, habe mich im Feld geirrt, nun wollen wir mal auf Erklärung warten, was nun wie berechnet werden soll
Gruß Oma
Hallo,
also wie ihr seht hat die Gesamtrezeptur nur ein Gewicht unter 1 Kg. Ich brauche die Rezeptur aber auf ein Kg umgerechnet und das zu den Entsprechenden Preis (auf 1 Kg Rezeptur).
Gruß
Baluga
Hallo,
anbei die Berechnung des Preises, wenn Gesamtmenge des Rezeptes auf insgesamt 1kg erhöht wird!
Ich würde aber dringend raten, die bestehenden Mängel zu beseitigen!!!
(Nachschlagfelder in Tabellen weg, Primär- und Fremdschlüssel immer Zahlen, Beziehungen über Zahlen, keine Formularbezüge in Abfragen, Datenherkunft mit gespeicherten Abfragen)
Gruß Oma
[Anhang gelöscht durch Administrator]
Puh, war das eine schwere Geburt.
Aber so klappt das. Danke an alle!
@oma:
Danke für die Berechnung. Hätte ich auch selber drauf kommen können (müssen), aber mit dem Brett vor meinem Kopf war das nicht möglich. Ich war zu sehr auf die berechneten Felder konzentriert. Danke!
@MzKlMu:
Danke für das Umbauen. Wieder was gelernt. Danke!
Gruß
Baluga