Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!

Mobiles Hauptmenü

Berechnungen im Unterformular

Begonnen von Baluga, August 29, 2010, 15:32:34

⏪ vorheriges - nächstes ⏩

oma

Hallo,

du findest hier mehr Helfer, wenn du die DB nach Access2003 konvertierts, da 2007 noch nicht viele(wie auch ich) benutzen.

Gruß Oma
nichts ist fertig!

MzKlMu

Hallo,
konvertiere die DB nach Access2003, Access2007 haben noch nicht so viele, ich auch nicht, kann daher die DB nicht öffnen.
Gruß Klaus

Baluga

Hier die 2003er Version!

[Anhang gelöscht durch Administrator]

MzKlMu

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]
Gruß Klaus

oma

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

nichts ist fertig!

MzKlMu

@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.
Gruß Klaus

oma

Hallo Klaus,

jo, habe mich im Feld geirrt, nun wollen wir mal auf Erklärung warten, was nun wie berechnet werden soll

Gruß Oma
nichts ist fertig!

Baluga

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

oma

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]
nichts ist fertig!

Baluga

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