Felder werden erst nach Aktualisierung berechnet

[MarkusR]

Hallo zusammen,

schon wieder ich. Ich arbeite grad an einem neuen Formular und hab hier ein kleines Problem mit berechneten Feldern:

Ich habe unter anderem folgende Felder: "curBearbeitung", "curMaterialEK", "curGesamt"

Das Feld "curGesamt" wird berechnet aus mehreren Feldern, unter anderem halt die oben genannten. Wenn ich bei "curMaterialEK" etwas eintrage, sehe ich in "curGesamt" sofort den neuen Wert. Wenn ich aber bei "curBearbeitung" etwas eintrage, wird das Feld "curGesamt" nicht neu berechnet. Nichtmal wenn ich den Datensatz verlasse und wieder reingehe. Ich muss erst aktualisieren bevor da was passiert. Beide Felder ("curBearbeitung" und "curMaterialEK") stammen aus der gleichen Tabelle, beides sind Währungsfelder und überhaupt seh ich da keinen Unterschied.

Hat jemand vielleicht auch schonmal so ein Problem gehabt? Weiß jemand Rat?

Vielen Dank im Voraus!

Beste Grüße, Markus

[MzKlMu]

Hallo,
berechne in der Abfrage, dann hast Du das Problem los.

Zeige mal die Formel, die Du im Formular verwendest.

[MarkusR]

Hallo,

der Code der bei "curGesamt" hinterlegt ist:

Code [Auswählen] Erweitern

=(([tabBestellungen.curBearbeitungStk]+[tabBestellungen.curRichtkostenStk]+[tabBestellungen.curSaegekostenStk]+[tabBestellungen.curSonderkostenStk]+[curClauss]+[curPartec]+[curBEVAB]+[curPMLLaser]+[curPMLWIG]+[curConnex]+[curRI]+[curExtern1]+[curExtern2]+[curExternAufschlag]+[curMaterialEKStk]+[curMaterialAufschlag])*[lngMenge])+[tabBestellungen.curRuestkosten]+[tabBestellungen.curWerkzeugkosten]+[tabBestellungen.curSonderkosten]+[curMaterialVerpackung]+[curMaterialTransport]

Meinst du mit "berechne in der Abfrage", dass ich dafür eine extra Abfrage machen soll oder meinst Du die Abfrage der Datensatzquelle?

Gruß, Markus

[MarkusR]

Aaaaaaaaaaahhhh, das ist ja genial 

Ich hab jetzt in der Abfrage der Datensatzquelle eine Spalte mit "curGesamt: Code wie unten" eingefügt, konnte dann im Formular als Steuerelementinhalt "curGesamt" auswählen und jetzt funktionierts wunderbar!

Vielen vielen Dank!

[MarkusR]

Öhm...jetzt bin ich verwirrt.

Die Datensatzquelle beruht auf mehreren Tabellen. Neben den Tabellen habe ich in der Abfrage jetzt noch 9 Spalten mit Berechnungen eingefügt. Bei der neunten Spalte kam jetzt allerdings die Fehlermeldung "Zu viele Felder definiert.". Liegt das jetzt an den 9 berechneten Feldern oder weil ich durch die mehreren Tabellen insgesamt zu viele Felder habe?

[DF6GL]

Hallo,

das Letztere dürfte zutreffen..

[MzKlMu]

Hallo,
Ergänzend:
Bei 255 Spalten ist die Grenze.
Wobei ich bei so vielen Spalten, auch wenn es eine Abfrage ist, erhebliche Zweifel am Datenmodell äußern würde.

Wie kommen denn die vielen Spalten zusammen?

[MarkusR]

Achso, ich dachte das mit den 255 Spalten würde nur für eine Tabelle gelten. Dass das auch für Abfragen gilt, wusste ich noch nicht.

Aufgrund der Tatsache, dass eine Tabelle nur 255 Spalten haben kann, wollte ich die Datenbank neu aufbauen. Ich habe daher mehrere Tabellen gemacht:

tabKunden - Kundenname, Adresse etc.
tabBestellungen - für alle Aufträge
tabProdukte - hier kommen alle Produkte mit Preis, Material etc. rein

und noch ein paar kleinere Tabellen, für Lieferscheine, Rechnungen, Mitarbeiter, Maschinenstunden usw.

Die drei oben genannten Tabellenen habe ich miteinander verknüpft. Wenn ich im Formular eine neue Bestellung anlege, erkennt er an der Zeichnungsnummer direkt den Rest der Produktes, wenn dies in der Tabelle tabProdukte angelegt ist. Leider haben wir sehr sehr viele Informationen, die wir zu den einzelnen Bestellungen oder Produkten speichern müssen. Da komme ich dann schnell auf die 255 Spalten.

[DF6GL]

Hallo,

Leider haben wir sehr sehr viele Informationen, die wir zu den einzelnen Bestellungen oder Produkten speichern müssen. Da komme ich dann schnell auf die 255 Spalten.

die Notwendigkeit für diese vielen Spalten kannst Du durch Normalisierung der Tabellen eliminieren.  Siehe u. st. Links 1 und 1a

[MzKlMu]

Hallo,

Leider haben wir sehr sehr viele Informationen, die wir zu den einzelnen Bestellungen oder Produkten speichern müssen. Da komme ich dann schnell auf die 255 Spalten.

da behaupte ich jetzt ganz provokant, ohne die Tabellen zu sehen, falsches Datenmodell. Siehe Normalisierungslinks von Franz.

Was sind denn das für Spalten bzw. was steht da drin, weil es so viele sind?

[MarkusR]

Also...

tabProdukte:
Angebotsnr., -datum
Anfragenr., -datum
Kunde
Angefragte Stückzahl
Angefragter Liefertermin
Angebotener Liefertermin
Artikelname, -nummer
Zeichnungsnr.
Artikel fertiger Durchmesser, Länge, Gewicht
Materialart
Materialrohdurchmesser 5mal (ein Produkt kann aus bis zu 5 Teilen bestehen)
Materialrohlänge 5mal
Materialrohgewicht 5mal
Preise für Bearbeitung, Richten, Rüsten, Sägen, Werkzeug, Sonderkosten, Verpackung, Transport
Kommentarfeld
Zu jedem Produkt werden Angebote von bis zu 5 Materialhändlern eingeholt mit Händlername, Preis pro Kg, Preis pro Stück, Transport, Verpackung, dazu noch Preisaufschlag von uns für das Angebot an unseren Kunden
Je nach Produkt werden noch Preise von externen Dienstleistern angefragt, auch hier wieder bis zu 5 Stück mit Dienstleistername, Dienstleistung, Preis, Transport, Verpackung, unser Aufschlag
Dann gibt es für jede unserer Maschinen drei Felder (ein Kontrollkästchen, ein Feld für Bearbeitungszeit, eins für Rüstzeit), in denen wir jeweils Erfahrungszeiten eintragen, wie lang wir etwa für das Produkt benötigen (hiermit möchten wir irgendwann mal eine vernünftige Kapazitätsauslastung planen können)


So, dann geht es zu tabBestellungen:
Bestellnr., -datum
Auftragsbestätigungsnr., -datum
Kunde
Zieltermin 1 und 2
Liefertermin
Menge
Zeichnungsnr.
Bearbeitungsart (Bearbeitung, Anfertigen, Nacharbeit o.a.)
Kommentar
Status
Rechnungsnr., -datum, -kommentar
Lieferscheinnr., -datum, -kommentar
Prüfzahl von und bis (manche Produkte werden mit Schlagzahlen durchnummeriert)
Rabatt 1 und 2 (hier kann man per Hand Rabatt vergeben)
Kontrollfeld Laufkarte (zeigt an, ob schon eine zu diesem Auftrag ausgedruckt wurde)
Materiallieferant
Materialbestelldatum
Materialwareneingangsdatum
Kontrollkästchen für Wareneingang
Materialrohmaße 5mal für Länge und Durchmesser (die tatsächlich bestellten Maße können leider von denen aus dem Angebot abweichen)
Materialpreis pro KG, pro Stück, Transport, Verpackung und unser Aufschlag (auch die können von den Werten aus tabProdukte abweichen)
Preise für Bearbeitung, Richten, Rüsten, Sägen, Werkzeug, Sonderkosten, Transport, Verpackung (können von tabProdukte abweichen)
Preise für externe Dienstleister
Bestellnummer, -datum, Lieferscheinnr., -datum für Bestellungen und Lieferungen an externe Dienstleister


So, das war jetzt mal ein Auszug, aus dem, was wir so brauchen. Vielleicht kann man das ein oder anderen wirklich noch durch Normalisierung rausholen. Aber für mich sieht das nicht so aus, als wäre das viel!

Vielen Dank für eure Hilfe!

[DF6GL]

Hallo,


grob gesagt, können alle diejenigen Angaben, die sich mehrfach wiederholen, in extra Tabellen ausgelagert werden:

z. B.  Materialmaße, Materialpreise, Materialangebote, Bearbeitungspreise,  und entspr. Tabellen zu tabBestellungen, wenn dort die Angaben von den Vorlagen aus der Produkttabelle abweichen sollen/können.



Ich empfehle nach wie vor das Anwenden der Normalisierung entspr. der vorher genannten Links.

[MarkusR]

Hallo,

die Links die du genannt hast, hab ich mir schon angeschaut. So ganz durchgeblickt hab ich noch nicht, muss mir das mal in ner ruhigeren Minute anschauen.

Das mit dem Auslagern verstehe ich nicht ganz: Ich habe ein Produkt X, Materialrohdurchmesser ist 75mm. Über Produkt X bekomme ich eine Bestellung, der Materiallieferant hat aber zur Zeit nur Material mit Durchmesser 80mm da und gibt mir das zum gleichen Preis. Bei der nächsten Bestellung über Produkt X bestelle ich aber wieder Material mit 75mm Durchmesser. Wie soll man das in einer Tabelle auslagern?

[MarkusR]

Hm, vielleicht hab ich es doch verstanden...

Wenn ich eine Tabelle mache für z.B. Materialbestellungen. Der Schlüssel ist natürlich die Bestellnummmer, die gleich der Bestellnummer aus tabBestellungen ist. Um jetzt auf die Daten aus der Tabelle zuzugreifen, mache ich im Formular ein Feld und hole mir per DomWert dann den benötigten Wert?

Ist das richtig oder bin ich noch komplett daneben?

[MzKlMu]

Hallo,
der Normalisierungsbedarf an den beiden gezeigten Tabellen ist so gewaltig, das passt gar nicht auf eine Monitorseite.  
Das sprengt auch den Rahmen dessen, was man hier erklären kann.

Daher mal nur das gröbste:
- Die Produkttabelle enthält nur die reinen Produktdaten. Da gibt es keinen Bezug zum Kunden. Wenn das Produkt an unterschiedliche Kunden geht ist eine Zuordnungstabelle Kunde-Produkt erforderlich.
- Alle Produkteigenschaften sind in eine eigene Tabelel auszulagern.
welche Eigenschaft zu welchem Produkt gehört wird dann auch über eine Zuordungstabelle geregelt
- Das gleiche gilt für die Preise.
Um das mal für die Preise beispielhaft zu machen. Du benötigst zunächst eine Tabelle für die Bearbeitungsschritte:
(Richten, Rüsten, Sägen, Werkzeug, Sonderkosten, Verpackung, Transport) jeder Schritt ist in dieser Tabelle ein Datensatz. Die Tabelle umfasst genau 3 Felder, den Primärschlüssel (Autowert) den Text des Schrittes und den Preis.
In die Zuordnungstabelle kommt denn die ProduktID, die ArbeitschrittID und der Preis (redundant wegen Preisänderungen)


Auch in der Bestelltabelle gibt es viele Ungereimtheiten.
Kann eigentlich immer nur ein Produkt je Bestellung bestellt werden?
Rohmaße, Preise, Gewicht usw. alles in separate Tabellen.


Ich halte den Aufwand hier eine normalisierte Struktur zu erstellen für groß bis sehr groß.
Und ohne normalisierte Struktur wirst Du hier auf keinen grünen Zweig kommen.

Um jetzt auf die Daten aus der Tabelle zuzugreifen, mache ich im Formular ein Feld und hole mir per DomWert dann den benötigten Wert?

Hier bist Du auf dem Holzweg, das laäuft alles über die Beziehungen und Abfragen. Du kannst auch davon ausgehen, sobald DomWert gebarucht wird, ist im Regelfall das Datenmodell falsch.