Access-o-Mania

Hallo liebe Access-Spezialisten,
ich hänge gerade an einem Formular fest....

Meinereiner hat 3 Tabellen mit folgender Konstellation:

• tbl_Artikel
• tbl_lieferanten_Artikel
• tbl_lieferanten

Den Artikeln (die später auch als Grundlage für die Auswahl der Bestellpositionen dienen) weise ich über eine n:m Tabelle (tbl_lieferanten_artikel) die Lieferanten zu.

Soweit so gut. Da es das Artikelformular bisher gab, allerdings ohne die Verknüpfung zu tbl_lieferanten, habe ich nun in der Datensatzherkunft die lief_ID_f hinzugefügt.

Mit dem Ergebnis, dass mir im Formular nun lediglich die Artikel angezeigt werden, welche auch schon einen Lieferanten zugeordnet bekommen haben.

Die Syntax lautet:
SELECT tbl_Artikel.*, tbl_Lieferanten_Artikel.Lief_ID_f
FROM tbl_Artikel INNER JOIN tbl_Lieferanten_Artikel ON tbl_Artikel.art_ID = tbl_Lieferanten_Artikel.Art_ID_f;

Ich vermute, dass das mit dem INNER JOIN zusammenhängt.

Nun meine Frage: Wie bekomme ich es hin, dass im Formular sämtliche Artikel aufgeführt sind, also auch die ohne zugewiesenem Lieferanten, sodass ich das bequem im Formular machen kann?

Und noch etwas für mein Grundverständnis hintendran:
Bei der Gestaltung eines Formulars aus mehreren Tabellen, ist es dann besser, die Tabellen als Grundlage zu nehmen oder das Ganze auf einer Abfrage basieren zu lassen?
Es geht mir auch darum, das ganze vor (versehentlichem) Überschreiben zu schützen.

Herzliche Grüße im Voraus aus dem Süden der Republik
Chris

Hallo,
das Formular für die Artikel darf nur die reine Artikeltabelle/Abfrage als Datenherkunft haben. Die lief_ID_f hat da nichts zu suchen.

Für die Zuordnung der Lieferanten wird im Artikelformular (=Hauptformular) ein Unterformular angelegt das über Art_ID und Art_ID_f verknüpft wird. Das Ufo erhält nur die Zwischentabelle/Abfrage (n:m Tabelle) als Datenherkunft. Die Auswahl des Lieferanten erfolgt über ein Kombinationsfeld das an lief_ID_f gebunden wird. Wenn Hafo und Ufo verknüpft ist wird der Fremdschlüssel zum Artikel (Art_ID_f) automatisch eingetragen.

Zitat.... Tabellen als Grundlage zu nehmen oder das Ganze auf einer Abfrage basieren zu lassen?

Im Regelfall ist es sinnvoll immer eine Abfrage anzulegen. Auch wenn nur ein Tabelle im Spiel ist. Sobald eine zuverlässige Sortierung benötigt wird (was meist der Fall ist) muss ohnehin zwingend eine Abfrage verwendet werden. Außerdem erstellt Access im Hintergrund selbst eine Abfrage auch wenn die Tabelle direkt verwendet wird.
Versehentliches Überschreiben hat mit Tabelle oder Abfrage nichts zu tun. Wenn Du Datensätze bearbeiten willst/musst, spielt es keine Rolle ob Tabelle oder Abfrage. Beides braucht Schreibrechte.

Hinweis:
Access legt bei Zahlenfeldern (auch bei den Fremdschlüsselfeldern xxxx-f) eine 0 als Standardwert fest. Bitte alle Zahlenfelder dahingehend prüfen und die 0 ggf. löschen.

ZitatIm Regelfall ist es sinnvoll immer eine Abfrage anzulegen.

Die aber möglichst nur auf einer Tabelle basieren sollte.

Zitat von: MzKlMu am Juli 15, 2023, 14:58:34Für die Zuordnung der Lieferanten wird im Artikelformular (=Hauptformular) ein Unterformular angelegt das über Art_ID und Art_ID_f verknüpft wird. Das Ufo erhält nur die Zwischentabelle/Abfrage (n:m Tabelle) als Datenherkunft. Die Auswahl des Lieferanten erfolgt über ein Kombinationsfeld das an lief_ID_f gebunden wird. Wenn Hafo und Ufo verknüpft ist wird der Fremdschlüssel zum Artikel (Art_ID_f) automatisch eingetragen.

Hmmm. Erstmal Danke für den ausführlichen Hinweis und Deine Mühe, habe ich soweit verstanden und ist auch (im Nachhinein) irgendwie logisch.
Nur scheint mir das mein Konzept etwas durcheinanderzubringen. Ich wollte eigentlich das Artiklformular zum Eintragen /Ändern/Anpassen der Artikel verwenden.
Heißt:
Pro Artikel eine Zeile (Endlosformular), bei dem ich dann den Artikel anlegen, dessen Eigenschaften (Artikelnummer intern, Art.-Nr. des Lieferanten, Rubrik/Artikelgruppe, Bezeichnung, etc.) eintragen und auch den Lieferanten in der Zeile per Dropdown (mit Verweis auf die tbl_lieferanten über die n:m-Tabelle auswählen kann. Aber halt alles in einer Zeile. Also so wie im Anhang....

Mit einem erforderlichen UFo scheint das ja so nicht zu funktionieren.
Wie löst man das dann am Geschicktesten in Access?

Zitat von: MzKlMu am Juli 15, 2023, 14:58:34Versehentliches Überschreiben hat mit Tabelle oder Abfrage nichts zu tun. Wenn Du Datensätze bearbeiten willst/musst, spielt es keine Rolle ob Tabelle oder Abfrage. Beides braucht Schreibrechte.

Heißt also, auch wenn ich eine  Abfrage erstelle, und auf dieser das Formular basieren lasse, dann schreibt Access über die Abfrage bei einem neu erstellten Datensatz die Werte in die der Abfrage zugrundeliegenden Tabelle?

Zitat von: Beaker s.a. am Juli 16, 2023, 11:46:24

ZitatIm Regelfall ist es sinnvoll immer eine Abfrage anzulegen.

Die aber möglichst nur auf einer Tabelle basieren sollte.

Okay... Ich dachte immer, dass der Vorteil einer Abfrage drin liegt, die Daten mehrerer Tabellen zusammenzuführen und auszuwerten...

Heißt für mich im Umkehrschluss: Für jedes Formular wäre es sinnvoll auf der zugrundeliegenden Tabelle eine Abfrage zu erstellen und diese dann als Datensatzherkunft zu nehmen?

Hallo Chris,

ZitatPro Artikel eine Zeile (Endlosformular),

Würde ich nicht machen. Für die "Haupt"entitäten (Kunden, Lieferanten, Artikel)
würde ich immer ein Einzelformular verwenden.
Gerade bei Artikeln gibt es so viele Abhängigkeiten (Lieferanten, Preise, Lagerbestände),
und die lassen sich in UFon sehr viel übersichtlicher darstellen.
Anbei mal ein Bild aus einer Fakturierung, die ich in den 00er Jahren mal entwickelt habe.

ZitatHeißt also, auch wenn ich eine  Abfrage erstelle, und auf dieser das Formular basieren lasse, dann schreibt Access

Ja, wenn die Abfrage aktualisierbar ist. Das ist in allen Fällen gegeben, wenn die
Abfrage auf einer einzigen Tabelle basiert. Abfragen mit JOINs muss man prüfen.

ZitatIch dachte immer, dass der Vorteil einer Abfrage drin liegt, die Daten mehrerer Tabellen zusammenzuführen und auszuwerten...

Das ist auch nicht verkehrt. Nur geht es hier nicht um Auswertungen (die müssen auch
nicht aktualisierbar sein), sondern um Datenpflege.

ZitatFür jedes Formular wäre es sinnvoll auf der zugrundeliegenden Tabelle eine Abfrage zu erstellen und diese dann als Datensatzherkunft zu nehmen?

Ist für mich Geschmackssache. DS-Herkünfte schreibe ich meist direkt in die Formeigenschaft.

gruss ekkehar

Hallo,

ZitatIch wollte eigentlich das Artiklformular zum Eintragen /Ändern/Anpassen der Artikel verwenden.

Das geht nicht bei einer n:m Beziehung.
Bei dieser n:m Beziehung kann ja ein Artikel mehrere Lieferanten haben. Wie trägst Du bei den Artikeln (also je Artikel eine Zeile) den 2. oder 3. Lieferanten ein ? Du hast ja je Artikel nur eine Zeile ?

ZitatArtikelnummer intern, Art.-Nr. des Lieferanten,

Die Artikelnummer des Lieferanten muss in die n:m Zwischentabelle, nicht in die Artikeltabelle.

Mal eine wichtige Frage: Wird bei Dir ein Artikel überhaupt von unterschiedlichen Lieferanten geliefert ?
Also Artikel A wird von Meier und Müller geliefert ?

Zitat... dann schreibt Access über die Abfrage bei einem neu erstellten Datensatz die Werte in die der Abfrage zugrundeliegenden Tabelle?

Eine Abfrage ist das Abbild einer Tabelle und speichert die Daten immer direkt in der zu Grunde liegenden Tabelle. Und zwar automatisch ohne irgendeine Rückfrage. Auch bei einem Datensatzwechsel sit sofort gespeichert. Ob Abfrage oder TAbelle direkt ist da bedeutungslos.
Eine Rückfrage (... soll das gespeichert werden ?) muss immer extra programmiert werden.

Zitat von: MzKlMu am Juli 16, 2023, 14:31:45Die Artikelnummer des Lieferanten muss in die n:m Zwischentabelle, nicht in die Artikeltabelle.

Macht Sinn. Gut erklärt, vielen Dank dafür. Werde die ganze Artikelgeschichte nochmal überarbeiten.... Dann lerne ich das wenigstens richtig.

Zitat von: MzKlMu am Juli 16, 2023, 14:31:45Eine Abfrage ist das Abbild einer Tabelle und speichert die Daten immer direkt in der zu Grunde liegenden Tabelle. Und zwar automatisch ohne irgendeine Rückfrage. Auch bei einem Datensatzwechsel sit sofort gespeichert. Ob Abfrage oder TAbelle direkt ist da bedeutungslos.

Auch das war mir so nicht bekannt. Gut zu wissen. Das mit der Nachfrage werde ich im Hinterkopf behalten...

Zitat von: MzKlMu am Juli 16, 2023, 14:31:45Mal eine wichtige Frage: Wird bei Dir ein Artikel überhaupt von unterschiedlichen Lieferanten geliefert ?
Also Artikel A wird von Meier und Müller geliefert ?

Selten, aber kommt doch auch mit vor.

Zitat von: Beaker s.a. am Juli 16, 2023, 14:13:35Würde ich nicht machen. Für die "Haupt"entitäten (Kunden, Lieferanten, Artikel)
würde ich immer ein Einzelformular verwenden.
Gerade bei Artikeln gibt es so viele Abhängigkeiten (Lieferanten, Preise, Lagerbestände),
und die lassen sich in UFon sehr viel übersichtlicher darstellen.

Scheint mir in jedem Fall sinnvoll. Werde da das Artikelformular nochmal anpassen. Bzw. gleich neu machen.
Das Konzept muss ich mir noch überlegen, aber da fällt mir bestimmt was ein. So perfekt wie das in Deinem Anhang wird's aber nicht, das kann ich schon jetzt sagen. ;D

Hallo,

ZitatSelten, aber kommt doch auch mit vor.

OK, dann ist n:m richtig. Hatte nur kurz Zweifel, daher die Rückfrage.
Die Preise hier noch mit zu erfassen wird jetzt noch komplizierter. Du brauchst eine Tabelle in der der Primärschlüssel der n:m Tabelle als Fremdschlüssel gespeichert wird und dann ein Feld für den Preis und ein Feld für das Gültigkeitsdatum. Jede Kombination Artikel - Lieferant hat dann einen oder mehrere Preise. Über das Gültigkeitsdatum wird dann der notwendige Preis ermittelt.

Oder eine einfachere Lösung:
Der aktulle Preis wird in der n:m Tabelle gespeichert und dann redundant in die Bestelltabelle übertragen (nach Auswahl eines Artikels.
Das erlaubt aber keine genaue Preishistorie.

Hallo Klaus,

ZitatOK, dann ist n:m richtig. Hatte nur kurz Zweifel, daher die Rückfrage.

Ich empfehle es immer gleich so anzulegen. Da muss man später nicht
umstrukturieren.

Zitatdann redundant in die Bestelltabelle übertragen (nach Auswahl eines Artikels.
Das erlaubt aber keine genaue Preishistorie.

Warum nicht? Mit einer Abfrage über die Bestellpositionen mit Bestelldatum bekomme
ich auch eine Historie. Ich habe das bei mir auch so gemacht. Hatte allerdings den
Grund, dass es öfter vorkam den vorgegeben Preis/Rabatt individuell anpassen zu müssen,
also nur für diese Bestellung.

gruss ekkehard

Danke an ekkehard und Klaus für die Tipps.
Heißt für mich: In der bpos_Bestellpositionen speichere ich den Artikelpreis zum jeweiligen Bestellzeitpunkt, den ich im Bestellformular (genauer: dem Ufo) eintrage? Klingt für mich erstmal einfacher als die erste Lösung und sollte auch völlig ausreichend sein....

Hallo,
@ekkehard

ZitatDas erlaubt aber keine genaue Preishistorie.

Die Betonung liegt auf "genaue".
Wenn der Preis z.B. zum 1.August geändert wird und ich erst wieder im Oktober bestelle, habe ich die Preisänderung nur zum Oktober (Bestelldatum) erfasst und nicht zum August. Wenn das reicht ist es auch gut.

Jep, das würde vollkommen reichen. Also der Preis zum Oktober.

Wann bzw. dass dieser geändert wurde, bekomme ich ja erst mit, wenn ich wieder bestelle (sofern ich nicht vorab vom Lieferanten neue Preislisten o.ä. bekomme). In der Regel frage ich den Preis zum benötigten Zeitpunkt an, verhandle den ggf. noch nach und bestelle dann. WANN der Lieferant intern die Preisänderung vorgenommen hat, ist für mich unerheblich.

Danke für den Tipp. So gaaaanz langsam steige ich im prinzi bei Access durch, ganz langsam.... :-\