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
Hallo,
berechne in der Abfrage, dann hast Du das Problem los.
Zeige mal die Formel, die Du im Formular verwendest.
Hallo,
der Code der bei "curGesamt" hinterlegt ist:
=(([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
Aaaaaaaaaaahhhh, das ist ja genial ;D
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!
Ö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?
Hallo,
das Letztere dürfte zutreffen..
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?
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.
Hallo,
ZitatLeider 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
Hallo,
ZitatLeider 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?
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!
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.
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?
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?
Hallo,
der Normalisierungsbedarf an den beiden gezeigten Tabellen ist so gewaltig, das passt gar nicht auf eine Monitorseite. ;D
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.
ZitatUm 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.
Hallo,
mhmm, fast richtig... ;)
Die "Bestellungen" bestehen aus zwei Tabellen: tblBestellkopf und tblBestellpostionen. In tblBestellkopf kommen alle diejenigen Daten/Werte hinein, die NICHT einer Bestellposition angehören, also Kundenadresse, Absender-Daten, Bestelldatum, Bestellkonditionen, usw. In tblBestellpositionen kommen NUR die Daten, die zu einer Position gehören, also MaterialNr, Menge, Einzelpreis(wenn der sich aktuell von dem hinterlegten EinzelpreistblMaterial unterscheiden kann) . Es werden in den Tabellen KEINE berechenbaren Werte gespeichert,also in tblBestellpositionen KEIN Positonspreis , in tblBestellkopf KEIN (Bestell-)Gesamtpreis.
In jeder Bestellposition wird (in einem Formular!) über ein Kombifeld, das seine Listendaten aus Tabelle tblMaterial bezieht, die Material_ID ausgewählt und als Fremdschlüsselwert im Datensatz gespeichert. Dabei können dann die evtl. aktuell veränderbaren Daten (siehe oben zu Einzelpreis) in die entspr. Felder übernommen (kopiert) werden.
tblBestellkopf und tblBestellpositionen stehen als 1:n-Beziehung mit ref. Integrität in Zusammenhang miteinander.
Hallo,
@MzKlMu:
Bisher werden alle Produkte in einer Tabelle gelistet, allerdings wird ein Produkt immer nur von einem Kunden bestellt (der Kunde schickt uns eine Zeichnung zu einem Produkt, wir erstellen das Angebot, jeder Kunde hat andere Produkte).
Was du mit auslagern meinst, habe ich glaube ich verstanden. Aber was bringt es mir, eine Tabelle zu erstellen mit ID, Arbeitsschritt und Preis, wenn ich dann in der Zuordnungstabelle zum Produkt wieder den Arbeitsschritt (diesmal als ID) und den Preis angebe? Klingt irgendwie doppelt. Aber davon mal abgesehen, versteh ich noch nicht, wie das mit der Zuordnung funktionieren soll. Mal ein Beispiel:
Produkt A: Bearbeiten 100 €, Richten 20 €, Rüsten 50 €
Produkt B: Bearbeiten 150 €, Richten 40 €, Rüsten 100 €
tblProdukte:
ID 1 Produkt A
ID 2 Produkt B
tblArbeitsschritte:
ID 1 Bearbeiten 100
ID 2 Richten 20
ID 3 Rüsten 50
ID 4 Bearbeiten 150
ID 5 Richten 40
ID 6 Rüsten 100
tblZuordnungProdukArbeitsschritt:
ID 1 ID 1 100
ID 1 ID 2 20
ID 1 ID 3 50
ID 2 ID 4 150
ID 2 ID 5 40
ID 2 ID 6 100
Ist das bis dahin so richtig dargestellt? Wenn ja, WIE mache ich das?! ;D
Ich meine, wie verknüpfe ich die Tabellen miteinander und wie wird ein Formular aufgebaut, dass ich die Daten da eingeben kann, ohne hunter Tabellen öffnen zu müssen?
In einer Bestellung wird immer nur ein Produkt bestellt, allerdings kann es vorkommen, dass die Bestellung gesplittet wird, da es mehrere Liefertermine gibt. Somit kann dann eine Bestellnummer öfters vorkommen.
Ich seh schon, das wird noch sehr viel Arbeit...und leider versteh ich scheinbar nichtmal die Grundstruktur :(
Habt Ihr sowas beruflich gelernt oder ist das nur "Freizeit" mäßig? Ich bin ja eigentlich nur n popeliger Kaufmann!
@DF6GL:
Sowas wie ein Bestellkopf ist eigentlich nicht nötig. Ein Produkt gibt es immer nur für einen Kunden und viele Kunden haben wir nicht gerade. Also kann man sowas wie Zahlungsbedingungen, Kundendaten usw. ja eigentlich in einer tblKunden speichern, oder?
Ach, was du da mit dem Kombifeld erklärst...ist das das mit dem Auslagern und der Zuordnung? Das würde aber bedeuten, dass zum Beispiel bei Materiallänge zehntausende von Werten in das Kombifeld müssten. Quasi alles zwischen 1mm und 14000mm länge.
Hallo,
lt. der Beschreibung nach "bearbeitest" Du gar keine Bestellungen, sondern Arbeitsaufträge. In diesem Fall (jeder Auftrag "produziert "ein anderes Produkt) ist auch keine Produkt-Tabelle nötig. Die Bestellnummer kann als "Auftragsnummer" angesehen werden, und die Liste der zugeordneten Arbeitsgänge (aus einer Stammtabelle entnommen) entspricht dem Fertigungsablauf. Diese Konstellation erfordert das Gleiche in Grün, also 3 Tabellen:
tblArbeitsgänge (wäre analog zu tblProdukte)
tblAufträge (wäre analog zu tblBestellkopf)
tblAuftragArbeitsgänge wäre analog zu tblBestellpositionen)
Wenn bei den einzelnen Arbeitsgängen Rohmaterial verarbeitet wird, das registriert werden soll, dann spielen da weitere Tabellen mit:
tblMaterial (1:n-Beziehung zu tblArbeitsgangMaterial)
tblArbeitsgangMaterial (in n: 1-Beziehung zu tblAuftragArbeitsgänge)
Das Gleiche gilt, wenn zusätzlich zum Material Arbeitszeiten von verschiedenen MAs beim gleichen Arbeitsgang erfasst werden müssen.
(Teil)-Lieferungen sind in einer "Bewegungstabelle" zu erfassen die als n-Tabelle an der "tblAufträge" hängt.
Hallo,
ich habe mir mal die Mühe gemacht und habe das mal an Hand des Beispiel aus Deinem letzten Beitrag umgesetzt.
Zunächst ist mal anzumerken, dass hier noch eine weitere Normalisierungstabelle fehlt. Die Bearebietungsschritte hast Du ja mehrfach in der Tabelle. Daher sind dazu 2 Tabellen notwendig. 1x für die Schritte und 1x für den Preis. In letzterer Tabelle ist dann ein Fremdschlüssel zum Schritt erforderlich.
Schaue Dir erst die Beziehungen an, dann das Formular. Du kannst im Ufo einen Arbeitsschritt zum Produkt auswählen im Kombi für den Preis wird ein Preis vorgeschlagen der zum Arb.Schritt passt. Der Preis wird in das Preisfeld übertragen und kann bei Bedarf geändert werden.
Das Beispiel beinhaltet jetzt nur die Beschreibung aus Deinem letzten Beitrag. Die Anmerkungen von Franz sind noch einzuarbeiten.
ZitatAber was bringt es mir, eine Tabelle zu erstellen mit ID, Arbeitsschritt und Preis, wenn ich dann in der Zuordnungstabelle zum Produkt wieder den Arbeitsschritt (diesmal als ID) und den Preis angebe?
In Deinem jetztigen Aufbau muss in der Grundtabelle für jeden Schritt eine Feld vorhanden sein, auch wenn der Schritt bei diesem Produkt gar nicht vorhanden ist. Bei korrekten Aufbau gibt es einen Schritt nur wenn dieser auch vorhanden ist.
Weiterhin, stelle Dir mal vor, Du musst irgendwann einen neuen Arbeitsschritt einführen?
Was dann? Jede Objekt (Formulare, Abfragen, Berichte) muss geändert werden, ausnahmslos.
Bei korrektem Aufbau ist das nur eine neuer Datensatz bei den Schritten und die Erfassung der Grundpreise, fertig,
alles passt immer noch.
ZitatHabt Ihr sowas beruflich gelernt oder ist das nur "Freizeit" mäßig?
Ich bin schon 8 Jahre Rentner (Sorry ;D ) und betreibe die Mitarbeit im Forum für Access als Gehirnjogging. Hatte früher im Beruf viel mit PC und EDV zu tun.
[Anhang gelöscht durch Administrator]
Guten Morgen!
Ersteinmal vielen Dank für Deine Mühe! Das macht mir das ganze doch schon um einiges verständlicher...
tblKunden trage ich einfach alle Kunden ein, die wir haben. Soweit klar.
tblProdukte kann ich durch die drei anderen Tabellen alle Produkte mit frmErfassung eintragen und hieraus die Angebote für meine Kunden erstellen.
ABER: Wie kommen die Preise in die tblArbSchrPreis? Wir haben ja für jeden Arbeitsschritt viele hunderte mögliche Preise. Trage ich da alle vorher von Hand ein? Oder werden die da irgendwie gespeichert, wenn ich ein neues Produkt anlege?
Und könntest Du mir vielleicht auch noch erklären, wie ich jetzt eine Tabelle mit meinen Aufträgen dazu verknüpfe? Da müsste ich doch jetzt eigentlich eine Tabelle tblAuftraege anlegen und die über eine Zuordnungstabelle, sagen wir tblZuordnungAuftragProdukt, mit der Tabelle tblProdukte verknüpfen, oder?
Ich glaube, ich komme der Sache so langsam näher...dank Euch!...aber da hab ich wohl noch eine ganze Menge Arbeit vor mir.
@Franz
Ich denke schon, dass eine Produkttabelle nötig ist. Da wir nicht jedes Produkt nur einmal produzieren, sondern ein Produkt immer wieder bestellt werden kann. Oder meintest Du das anders?
Ich habe jetzt mal eine Tabelle tblAuftraege mit den Felder "AuftragsID", "Auftragsnummer" und "ProduktID_F" erstellt und diese mit der Tabelle tblProdukte verknüpft.
Dann habe ich eine Formular frmAuftraege mit den Feldern "Auftragsnummer" und "ProduktID_F" erstellt, das Formular tblErfassung als Unterformular eingefügt und vom Unterformular zum Hauptformular verknüpft mit den Feldern "ProduktID" und "ProduktID_F". Ist das so richtig?
Hab die Datei mal mit hochgeladen.
[Anhang gelöscht durch Administrator]
Hallo,
es nutzt absolut nichts, Formulare zu erstellen, wenn die Tabellenstruktur noch nicht KOMPLETT klar und vollständig ist..
ZitatIch denke schon, dass eine Produkttabelle nötig ist. Da wir nicht jedes Produkt nur einmal produzieren, sondern ein Produkt immer wieder bestellt werden kann.
Wenn, wie ich es jetzt (noch) sehe, ein "Produkt" identisch einhergeht mit einer fertigungs-/projektbezogenen Auftragsabwicklung, dann ist ein Produkt (Produktnummer) lediglich ein Attribut eines "Auftrages" wie vorher schon erwähnt und braucht nicht als eigene Tabelle geführt zu werden, weil der reale Fertigungsablauf mit allen seinen Eigenheiten (Rohmaterial, Arbeitsgänge, evtl. auch Vorgabe-Arbeitszeiten) genau dieses "Produkt" spezifiziert.
Hallo Franz,
dass ich jetzt noch keine Formulare ausarbeite ist auch klar. Sollte nur zur Veranschaulichung dienen. Man kann natürlich auch nur die Tabellenstruktur betrachten.
Wenn ich Dich richtig verstehe müsste ich also statt einer tblProdukte eine tblAuftraege machen, in der ich dann das Produkt spezifiziere. Aber hat man dann auch die Möglichkeit, auf ein bereits bestehendes Produkt zurück zu greifen?
Hallo,
ZitatMan kann natürlich auch nur die Tabellenstruktur betrachten.
NUR das sollte man in dieser Phase..
Ich hatte das Ganze doch letzthin beschrieben..?
Letztendlich musst Du entscheiden/erkennen, ob solche Datenkonstellation für Euch zutrifft. Wenn nicht, dann muss das halt noch verändert/angepasst werden. Ich (wir) selber kann (können) die Sachlage nur aus Deinen Schilderungen ablesen..
Zitatauf ein bereits bestehendes Produkt zurück zu greifen
Hier derselbe Hinweis: wenn "Produkt" == "Projektauftrag" dann besteht diese Möglichkeit .
Guten Morgen zusammen,
Betriebsferien sind vorbei, der Stapel auf meinem Schreibtisch ist abgearbeitet...jetzt habe ich wieder Zeit, mich hiermit auseinander zu setzen.
Ich habe jetzt mal dein Zuordnungsbeispiel um zwei Tabellen erweitert: tblAuftraege und tblZuordnungProduktAuftrag
Die Tabellen habe ich dann in den Beziehungen verknüpft. Ist das richtig, wie ich das gemacht habe?
Mir stellt sich jetzt die Frage, wie man damit arbeitet? Ich meine, unsere Mitarbeiter wissen ja nicht, welches Produkt welche Produkt ID hat. Kann man nicht statt einer Produkt ID als Schlüssel die Zeichnungsnummer kombiniert mit dem Angebotsdatum nehmen?
Ich werde jetzt erstmal versuchen, die Tabellen zu normalisieren...das wird wohl was dauern ;D
Danke und Gruß,
Markus
[Anhang gelöscht durch Administrator]
Hallo,
ZitatKann man nicht statt einer Produkt ID als Schlüssel die Zeichnungsnummer kombiniert mit dem Angebotsdatum nehmen?
Nein, das wäre ein fataler Fehler.
Die ID bekommt auch niemand zu Gesicht. Die Auswahl erfolgt mit einem Kombi in dem die ID ausgeblendet wird und die Klartextfelder angezeigt werden.
Hallo,
die Tabellen sind doch schon normalisert... wenngleich bei tblArbSchrPreis noch irgendein Unterscheidungsmerkmal für die verschiedenen Preise eines Arbeitsschrittes fehlt (z. B. ein Gültigkeitsdatum und/oder auch eine Mengenstaffelung). Weiterhin ist ein bestimmtes "Produkt" (würde eher sagen: "Herstellungsablauf") an lediglich nur einen Kunden gebunden. Falls das nicht zutrifft, muss tblKunden an tblAuftraege angebunden werden.
Wenn "Produkt" eigentlich eine "Liste von definierten Arbeitsschritten" ,( bzw. "Herstellungsablauf") bedeutet und eindeutig von der Zeichnungsnummer abhängt, dann reicht es, dass bei der Erstellung eines Auftrages die Zeichnungsnummer vom User ausgewählt wird, die er ja in diesem Moment kennen muss. Die ProduktID bleibt aber so wie sie ist...
Hallo,
Zitat von: MzKlMu am Januar 14, 2013, 10:58:49
Die ID bekommt auch niemand zu Gesicht. Die Auswahl erfolgt mit einem Kombi in dem die ID ausgeblendet wird und die Klartextfelder angezeigt werden.
Ah, okay...dann wird mir das schon klarer. Wenn ich einen neuen Auftrag anlege, könnte ich quasi über ein Kombifeld eine Artikelnummer wählen, zu der mir dann die verschiedenen Zeichnungsnummer und das jeweilige Angebotsdatum zu der Zeichnung angezeigt werden.
Zitat von: DF6GL am Januar 14, 2013, 11:03:26
die Tabellen sind doch schon normalisert...
Ich meinte auch nicht die in dem Beispiel, sondern meine eigene (oben beschriebene) Tabelle. Hab mir dazu deinen Link 1a nochmal angeschaut, den find ich halbwegs verständlich :). Im ersten Schritt schaue ich, dass in keinem Feld mehr als 1 Wert ist. Im zweiten Schritt muss ich dann schauen, dass ich Tabellen erstelle, in den die Attribute nur vom Schlüssel abhängig sind. Den dritten Schritt habe ich noch nicht verstanden...aber so weit muss ich erstmal kommen!
So, ich hab das Beispiel jetzt mal um ein gutes Stück erweitert. Könnte bitte da mal jemand von euch drüber schauen, ob ich jetzt endlich auf dem richtigen Weg bin?
Dankeeee ;)
[Anhang gelöscht durch Administrator]
Hallo zusammen,
anbei hab ich nochmal die aktuelle DB hochgeladen. Habe jetzt neben den Tabellen, die ich zur Produkterfassung benötige, auch noch ein Formular mit Unterformular angefangen.
Ersteinmal: Ist die Tabellenstruktur jetzt so richtig? Wäre ja Quatsch mit weiteren Tabellen anzufangen, wenn ich das immer noch nicht richtig verstanden habe.
Dann ist mir aber beim Erstellen des Formulars etwas aufgefallen: Bisher arbeiten wir mit einem geteilten Formular. Da sieht man dann zum Formular auch alle Produkte im Datenblatt, die bisher angelegt wurden. Das ist auch wichtig für unsere Arbeit. Wenn ich jetzt aber ein Unterformular in das Hauptformular einfüge, sieht man die Spalten vom Ufo ja nicht im Datenblatt des Hauptformulars. Gibts da irgendeine Möglichkeit?
Im Voraus tausend Dank für Eure Hilfe!
Gruß, Markus
[Anhang gelöscht durch Administrator]