hi networker,

was du willst versteht wohl keiner... ich auch net. Sonst hätte bestimmt schon jemand geantwortet.

Also

du willst Daten, die sich verändern, von Tabelle 1 nach 2, aber ohne das sich die Daten in Tabelle 2 verändern???

Was sind das für Daten? ...

Wenn du eine Lösung haben willst, mußt du mal sehr konkret ein Beispiel hier posten, damit das Problem allen verständlich wird...

Gruß Leo

Hallo Leo,

du hast recht meine Abhandlung ist schwer nach zu vollziehen ;).

Ich nenne mal ein einfaches Beispiel.

Kassensoftware für einen Gemüseladen, die Preise ändern sich täglich. (ist ja nur ein Beispiel)
Und am Monatsende muss die Abrechung gemacht werden.

Nun gibt es drei Tabellen:
1. Tab.-Artikel
2. Tab.-Bestellungen
3. Tab.-Kunden

Tabelle Artikel steht mit Tabelle Bestellungen in Beziehung und Tabelle Bestellungen steht mit Tabelle Kunden in Beziehung.
Aufgrund der Preisänderung würden sich die Preise in der Tabelle Bestellungen auch immer mit ändern.
Ziel ist es wenn ein Datensatz angelegt wird in der Tabelle Bestellungen, dass dieser Später nicht mehr geändert werden kann. (Preis)

Ich hatte schon an eine Anfüge Abfrage gedacht.
So könnte ich den Preis aus der Tabelle Artikel in der Tabelle Bestellungen mit Speichern.

Aber es gibt bestimmt noch einen anderen einfacheren Weg.

Vielen Dank für eure Mühe.

Gruß networker

Hallo Networker,

wenn ein Kunde heute eine 10 kg Kiste Bananen zum Preis von 7,90 € bestellt, dann sollte seine Rechnung auch am Ende des Monats sich noch auf 79 € belaufen, und nicht plötzlich auf 99 €, oder?

Deine Tabelle Bestellungen darf also keine vom Tagespreis abweichenden Einträge aufweisen. Sprich, die Beziehung zu der Tabelle Artikel kann nur in Bezug auf die Artikel selber stehen, nicht aber grundsätzlich zu deren Preis.

Wenn also eine neue Bestellung eingeht, bekommt der Kunde zwar den Preis aus der Artikel einmal mit in die Tabelle Bestellung, aber für die Rechnung bezieht sich der Preis nur auf die Einträge in der Tabelle Bestellung.

So, ich denke bis dahin sind wir uns ja einig. Aber nun zu deiner Frage, wie man das realisiert.

Eigentlich ganz einfach.

Du erstellst ein Formular für die Erfassung die Bestellungen. In diesem Formular sind alle Artikel, die der Kunde bestellen kann hinterlegt, und natürlich auch der Tagesaktuelle Preis der Bestellung.

Diesen Datensatz fügst du an die Tabelle Bestellung an, wobei auch die Kundennummer und das aktuelle Datum mit übergeben wird.

Willst du nun zB die Rechnung schreiben, brauchst du einen Bericht, der dir für diesen Kunden, diesen Tag und diese Bestellung einfach diese Daten ausgibt, und zwar mit den Kundendaten aus der Tabelle Kunden, der Artikelbeschreibung und -Nummer aus der Tabelle Artikel, den Preis, die Menge und die Endsumme berechnet + 19% Mehrwertsteuer natürlich aus der Tabelle Bestellung.

An keiner Stelle schreibst du nach der Erfassung der Bestellung den Preis erneut in die Tabelle Bestellung...

Gruß leo

@ leo vielen Dank für die Antwort erstmal ;)



völlig richtig



so ist es



es ist alles ganz einfach wenn man weiss wie es geht ;)



Habe ich gemacht



so sollte es sein, ich hatte schon in den Feld-Eigenschaften "Anfügen = ja" eingegeben aber es klappt nicht ?
Der Wert wird immer aus der Tabelle Artikel bezogen :(



der Bericht ist kein Problem der ist schon vorhanden

moin moin

"Diesen Datensatz fügst du an die Tabelle Bestellung an, wobei auch die Kundennummer und das aktuelle Datum mit übergeben wird."



Wenn dem so ist, dann hast du das Feld Preis aus der Tabelle Artikel angezogen und nicht das aus der Tabelle Bestellungen.

Der Knackpunkt ist also die Datenquelle, mit der du arbeitest. Das hat mit irgendwelchen Einstellungen im Formular nichts zu tun. Anfügen zulassen mit Ja zu hinterlegen, bedeutet nur, daß man Datensätze hinzufügen kann, aber nicht, daß automatisch ein Datensatz erzeugt wird.

Poste moch mal die Abfrage bzw Quelle, die deinem Formular zugrunde liegt. Irgendwo müssen die Daten ja herkommen, nä! Und da ist wahrscheinlich irgendwo der Fehler.

Und wie ich so gerade lese was du geantwortest hast, nochmal die Frage: Wenn du eine Bestellung generierst, MUSS der Preis aus der Tabelle Artikel kommen. Erst danach darf sich der nicht mehr ändern! Korrekt? Denn wo soll der Preis sonst herkommen???

Gruß Leo

Hallo,

ich Poste mal die SQL Abfrage die in dem Formular liegt.
evl. kannst du ja einen Fehler finden.

SELECT Artikel.Name, Bestellung.BestellNR, Bestellung.ANR, Bestellung.Menge, Bestellung.Preis, Bestellung.KNR FROM Artikel RIGHT JOIN Bestellung ON Artikel.ANR=Bestellung.ANR; 

richtig - genau so ;)

Danke + Gruß

Hallöle,

also wenn ich das richtig sehe...



kannst du die Tabelle Artikel aus dem Formular - SQL - String komplett entfernen. Wenn du den Artikelnamen anzeigen lassen willst, greifst du einfach auf:

Me!Artikelname.Value = DLookUp("Name","Artikel","ANR='" & Me!Artikelnummer.Value & "'")

zurück. Eine Fehlerquelle abgeschaltet!

Dann dürfte dein Formular-String nur noch auf die Tabelle Bestellung zurückgreifen.

Und auch wieder der Hinweis: Wer sollte hier den Preis verändern? Außerdem hast du es ja richtig hinterlegt: Bestellung.Preis... Wieso verändern sich also deine Preise in der Bestellung? Hast du vielleicht irgendwo eine aktualisierungsabfrage, die das macht???

Gruß leo

Hallo,

sry das ich mich erst jetzt melde, letzte Woche war die Zeit in wenig knapp.

Ich habe mal den Script eingefügt in das Formular.
Bei dem Aufrufen von dem Formular, kommt jetzt die Fehlermeldung das die angegebene Datenquelle nicht vorhanden ist.

Gibt es nicht irgendwo ein Beispiel wo ich mir das mal anschauen kann?

Gruß networker

Hallo networker,

mit deiner momentanen Tabellenkonfiguration dürftest du keine Beziehung zwischen den Tabellen Artikel und Bestellungen haben, denn du änderst ja damit die alten Preise, wie du schon bemerkt hast. Stattdessen müsstest du (nur!) den Preis aus der Tabelle Artikel als Kopiervorlage betrachten, der beim Erstellen einer neuen Bestellung herangezogen wird und direkt in der Bestellung als unabhängige Kopie gespeichert wird. Damit hättest du die Unabhängigkeit zwischen dem Preis in Artikel (den du dann jederzeit ändern kannst) und den Bestellungen.

Dieses Vorgehen gilt nur für das Prinzip ein Datensatz pro Artikel und Preis

Allerdings würde ich das nicht als ideale Lösung bezeichnen. Ich würde stattdessen der Tabelle Artikel eine neue, untergeordnete Tabelle Preishistorie verpassen. Die kennt neben dem eigenen Primärschlüssel nur ein Preisfeld und ein Datumsfeld. Bei jeder Preisänderung eines bestimmten Artikels wird in der Preishistorie ein neuer Datensatz mit "Gültig ab"-Datum hinzugefügt. Bereits vorhandene Datensätze werden nie wieder geändert.

Da die beiden Tabellen Artikel und Preishistorie in Beziehung stehen, kommst du auch automatisch vom Preis rückwärts zum zugehörigen Artikel. Daher kannst du auch die Tabelle Bestellungen direkt mit der Preishistorie verknüpfen, statt mit der Tabelle Artikel.

Wenn du also eine neue Bestellung anlegst, dann musst du dir über eine Abfrage alle Artikel mit deren aktuellen Preisen (z.B. pro Artikel das Datum absteigend sortieren, dann erster Eintrag) zurückgeben lassen und dann den ebenfalls ausgegebenen Primärschlüssel des Preises an die Bestellung zuweisen.

Bei einer evtl. späteren Bearbeitung einer vorhandenen Bestellung könntest du auf die Filterung aller veralteten Preise verzichten und dir schön nach Datum sortiert alle Preise anbieten lassen und auswählen - sofern du das gebrauchen kannst.

Aus meiner Sicht würde ich diese Variante für dich als ideal erachten.

Hier nochmal eine schematische Skizze.

Vorher:
Artikel --> Bestellung <-- Kunde

Nachher:
Artikel --> Preishistorie <-- Bestellung <-- Kunde

Gruß
erik

Hallo,

also Erik ich muss sagen die Idee ich einfach echt gut ;)

Ich muss nur mal schauen ob ich das für meine Berechnungen auch verwenden kann.

Vielen Dank !

Gruß networker

Hallo,

also Erik ich muss sagen die Idee ich einfach echt gut ;)

Ich muss nur mal schauen ob ich das für meine Berechnungen auch verwenden kann.

Vielen Dank !

Gruß networker

Hallo,

ich sitze grade an einer Lösung von dem Beispiel von Erik.
Leider komme ich grade nicht weiter :-(...

So sehen die Beziehungen aus:


Die Funktion die die neue Tabelle Preishistorie erfühlt ist mir klar.

Die Frage ist nun was für ein Wert soll in Tabelle Bestellung?
Die Tabellen Preishistorie und Artikel haben jeweils Primärschlüssel, welcher soll da eingetragen werden?

Vielen Dank

Gruß networker

Hallo networker,

dem Bildschirmfoto nach sind die Beziehungen richtig definiert. Bei der Festlegung des Preises musst du zwischen zwei Varianten unterscheiden:

1. Preise für neue Bestellungen
Hier sollte NUR der neueste Preis pro Artikel angezeigt werden. Das kann dir eine Abfrage liefern, die z.B. ein Preise-Kombinationsfeld in deinem Bestellungsdatensatz füllt. Der zurückgegebene Primärschlüssel des Kombinationsfeldes wird dann an die Tabelle Bestellung zugewiesen.

2. Preise für vorhandene Bestellungen
Sofern das notwendig sein sollte, kannst du nachträglich eine Bestellung mit einem älteren Preis aktualisieren. Der Filter nach dem neuesten Preis fällt hier einfach weg.

Du kannst des dir natürlich noch einfacher machen. Lasse pauschal alle Preise des aktuellen Artikels nach Datum absteigend anzeigen, dann brauchst du stets nur den ersten Eintrag auszuwählen, der wäre dann sowieso aktuell. Das gibt dir bei der Ersterfassung auch die Möglichkeit, ausnahmsweise einen älteren Preis auszuwählen, evtl. als Rabatt oder sowas. :-)

Wie auch immer, bei der Erfassung wirst du stets darauf angewiesen sein, dass du den Preis per Kombinationsfeld auswählst. Was dir dabei das Kombinationsfeld im Endeffekt anbietet, ist reine Ermessenssache, was eben sinnvoll erscheint.

Wenn du später dann die Bestelldaten ausgeben willst (z.B. Bericht), dann darfst du natürlich nicht vergessen, beide Tabellen Bestellungen und Preishistorie in die Ausgabeabfrage aufzunehmen. Über den gespeicherten Primärschlüssel wird dann automatisch der passende Preis zurückgegeben.

Jetzt nochmal die Superkurzfassung:
Deinem Erfassungsformular liegt die Tabelle Bestellung zugrunde. In diesem Erfassungsformular muss es ein Kombinationsfeld geben mit der Tabelle Preishistorie als Datenherkunft. Dessen Primärschlüssel pid muss im Formular im Feld pid gespeichert werden.

Gruß
erik

Hallo Erik,

vielen Dank für deine Erläuterungen.

So wie du das in Punkt eins beschrieben hast, würde ich auch vorgehen.

Ich habe auch schon eine Abfrage angelegt:

SELECT Max(preishistorie.pid) AS Maxpid, preishistorie.aid
FROM preishistorie
GROUP BY preishistorie.aid;

Diese gibt immer höchsten Wert von "preishistorie.pid" zurück.

Irgendwie habe ich jetzt einen Denkfehler bei dem Einbinden der Abfrage in das Formular.
Aus irgendeinem Grund legt er die pid nicht in der Tabelle Bestellung ab?

Was würdest du empfehlen?

Gruß networker

Hallo,

deine Abfrage ist völlig falsch. Probiere es damit:

SELECT preishistorie.pid, preishistorie.datump, preishistorie.preis, preishistorie.aid
FROM [SELECT preishistorie.aid, Max(preishistorie.datump) AS datump
FROM preishistorie
GROUP BY preishistorie.aid]. AS Temp INNER JOIN  preishistorie ON (Temp.aid = preishistorie.aid) AND (Temp.datump = preishistorie.datump);

Die eingebettete Unterabfrage gruppiert nach Artikel und liefert das letzte Datum pro Artikel. In der darüberliegenden Abfrage werden aufgrund dieser Daten alle Spalten aus der Tabelle preishistorie angezeigt.

Wie ich schon erwähnte, diese Abfrage muss an ein Kombinationsfeld gebunden werden. Das zeigt dir meinetwegen Preis und/oder Datum an, liefert aber intern den Primärschlüssel zurück, der in der Bestellung gespeichert wird.

Gruß
erik

Hallo erik,

vielen Dank für die Abfrage ;)

Ich habe diese mal vorsichtig in ein Formlar ein gebunden, ich erhalte aber immer ein "FROM-ERROR".

Ich wollte jetzt erstmal die Errebnisse von der Abfrage in die Tabelle Bestellung.pid eintragen.

Ist das soweit erstmal richtig?

Aber bestimmt nicht, sonnst würde es ja gehen :-/

Gruß networker

Hallo,

läuft diese SQL-Anweisung in einer Abfrage? Wird in der SQL-Ansicht eine bestimmte Stelle markiert, wenn ein Fehler auftritt? Stimmen die Tabellen- und Feldnamen?

Hallo erik,

ich habe noch mal neu angefangen und jetzt sieht es schon ganz gut aus ;)

Wenn du willst kannst du es dir ja mal anschauen:
http://www.file-upload.net/download-480369/test.mdb.html

Technisch gesehen habe ich mir das so vorgestellt oder was meinst du?

Gruß networker