Problem mit Abfrage

[Eleinad]

Hallo,

Ich arbeite derzeit an meiner ersten Datenbank in der ich versuche Prozessdaten und zugehörige Tests zu Tracken und in einem Bericht zusammenzuführen.

Ich habe eine Haupttabelle, in dieser vergebe ich für jeden Prozess einen Code der als Fremdschlüssel für sämtliche anderen Tabellen und abfragen dient.

Ich habe eine Abfrage die prüft ob alle Testdaten vorhanden sind, und eine Abfragen die alle Daten für mein Bericht zusammenführt.

Folgendes Problem: wenn ich meine Tabellen in der finalen Abfrage zusammenführe, lässt Access keine Bearbeitung zu. Ich kann im Formular zur Abfrage über das DropDown Menü das den Produkt Code referenziert nicht durch die einzelnen Prozessläufe navigieren. Ich habe auch ein Fortlaufendes Formular erstellt in dem die Prozessläufe als Liste angezeigt werden, hier wiederholt sich Prozesslauf 1 fortlaufend bis zum Absturz von Access.

Powerpoint

Legende zu PPT:
Buttons blau, Tabellen grün, Abfragen gelb

Erlaub Access evtl. nicht das Querreferenzieren in den Formularen?

Beste Grüße,

Dan

[MzKlMu]

Hallo,
die abstrakten Folien helfen nicht wirklich.
Besser wäre ein Bild des Beziehungsfensters hier im Forum hochgeladen.

[Debus]

Hallo, da Du doch noch im Beginn der ganze Sache bist, sollten da ja noch keine Echtdaten enthalten sein. Lade doch einfach mal die DB hoch.

Holger

[Bitsqueezer]

Hallo,

da es Deine erste Datenbank ist, gleich ein paar Hinweise, die Du beachten solltest, wenn Du Tabellen erstellst.

In einer Datenbank geht man zeilenorientiert vor. Sobald sich ein Feld in einer Datenzeile wiederholt, wobei es den gleichen Datentyp und den gleichen Zweck erfüllt, handelt es sich um Aufzählungsfelder, und die gehören in eine Untertabelle als Zeilen der neuen Tabelle. Als Beispiel sei hier "Test1" bis "Test18" aufgeführt. Stattdessen hast Du eine ID eines Produktes mit einer Tabelle für ein Produkt, die nur das Produkt selbst beschreibt, z.B. Name und andere Attribute, aber keinerlei Eigenschaften, die zu Tests oder Verkauf oder Bestellung usw. gehören, da dies in eigenen Tabellen beschrieben wird, die alle eine ProduktID aufweisen, um auf die Produktbeschreibung selbst zugreifen zu können, ohne sie zu wiederholen.
Entsprechend (je nach Anforderung) gibt es z.B. eine Testreihe, die aus x Einzeltests für ProduktID 27 besteht. Dann gibt es eine Tabelle, die die Testreihe definiert, also welche ProduktID, Name der Testreihe o.Ä., und sonstige Daten, die wichtig sind, um alle zugehörigen Tests gemeinsam zu beschreiben. Dazu zählt z.B. nicht die Anzahl der Tests.
Dann gibt es eine Tabelle, die jeden Test einzeln beschreibt. Diese enthält die Verbindung zur zugehörigen Testreihe über eine TestreihenID, dagegen nicht die ProduktID - weil Du über die TestreihenID auf die richtige Zeile der Testreihe kommst, dort schon eine ProduktID existiert und weil Du über diese wiederum alle Daten zum Produkt abrufen kannst. Und weil "Tests" eine eigene Tabelle ist, spielt es keine Rolle, ob Du 3 oder 57 Tests durchführst in der gleichen Testreihe, Du kannst von 0 bis unendlich (naja, also bei einer Long ID so etwa 2,1 Milliarden..) soviele Tests verwenden, wie Du willst. Programmiertechnisch muß dann nichts mehr daran geändert werden, wenn Du statt 18 plötzlich 22 Tests brauchst, was in Deinem Setting nötig wäre.
Das ist nur ein ganz simples Beispiel, das noch weiter ausgebaut wird mit ähnlichen über- und untergeordneten Tabellen. Dabei ist vor allem wichtig, daß Du mindestens das Konzept von 1:n und n:m kennst und verstanden hast, wann man was einsetzt, das Beispiel hier wären jetzt alles 1:n-Tabellen.

Eine andere wichtige Sache ist: Gewöhne Dir gleich von Beginn an an, keine Leer- und Sonderzeichen in Objektnamen wie Tabellen- und Feldnamen zu verwenden, auch keine Umlaute. Das führt später zu Problemen. In Feldnamen gehören auch keine Angaben zu Einheiten wie "Länge (m)". Stattdessen einfach "Laenge". Eine Einheit kann man später in der Beschriftung (Label) in Formularen und Berichten anzeigen, wo es für den Benutzer interessant ist. Außerdem könnte Dir später einfallen, daß Du doch lieber cm verwenden willst und dann hast Du in allen Namen "(m)" drinstehen, was dann falsch ist. Aus dem gleichen Grund gibt man, im Gegensatz zu VBA, keine Datentypenprefixes an, also nicht "intLaenge". Denn vielleicht willst Du später den Datentyp von int auf decimal ändern und dann sind die Namen überall ebenso falsch.
Es ist ebenfalls gut, wenn man gleich von Anfang an eine Sprache verwendet. Also entweder alle Namen in Deutsch oder alle Namen in Englisch.
Es empfiehlt sich außerdem, bei den "großen" Objekten Präfixes zu verwenden, also "tbl" für Tabelle, "qry" für Abfrage, "mod" für VBA-Module, "cls" für VBA-Klassenmodule, "frm" für Formulare und "rpt" für Berichte (Report). Im Gegensatz zu den Überlegungen oben wird sich deren Typ niemals ändern. Eine Tabelle wird nicht plötzlich eine Abfrage und ein Report wird nicht plötzlich ein Formular. Wenn man aber aus Listen Namen schnell wiederfinden will, ist es sehr gut, wenn man Prefixes hat, die einem gleich sagen, was man hier vor sich hat. So gibt es viele Query-Editoren, die von einer Datenbank z.B. alle Tabellen, Abfragen, Funktionen und Prozeduren (gemeint sind hier Stored Procedured von Datenbankservern) als eine große Liste, alphabetisch sortiert anzeigen. Da ist es dann schwer, die richtige Auswahl zu treffen.

Zu Deinem Problem: Einerseits kann man Pivot-Tabellen erstellen, die einem die oben zeilenweise Definition von Tabellen auch wieder in Spalten verwandeln können, was für Berichte wunderbar ist - aber so werden die Daten in einer Datenbank nicht eingegeben.
Beim Eingeben arbeitet man ebenso nur zeilenweise, so wie es i.d.R. die Tabellendefinition vorgibt.
Eine Abfrage, die man aus mehreren Tabellen zusammenführt, KANN bearbeitbar sein und Access kann tatsächlich hier mehr als andere Datenbanken, aber grundsätzlich gilt die Regel, daß ein UPDATE/INSERT/DELETE immer nur genau EINE Tabelle verändern kann. Das gilt auch für z.B. Views bei SQL Server, die scheinbar mehrere Tabellen gleichzeitig speichern können - dahinter steht dann in der Regel ein Trigger, der die Daten auseinandernimmt und auf die einzelnen Tabellen aufteilt. Access kann das nicht, kann aber bisweilen durch Beziehungsdefinition selbst herausfinden, wo es passende Daten in übergeordneten Tabellen selbst erzeugen kann. Das sollte man aber besser vermeiden, denn meistens handelt es sich um Stammdaten (wie die Produktbeschreibung), die sich nicht mit jedem Test ändern sollen, es soll also bewußt vermieden werden, daß ein Benutzer, der den Test eingibt und alles in einer Sammelabfrage hat, hierbei auch die Produktdaten ändert im Glauben, das gehöre zu dem Test - und in Wirklichkeit ändert er damit die Produktdaten für ALLE.

Also: Alles, was Daten verändert, soll sich immer nur auf EINE Tabelle beziehen. In einem Formular können dabei zusätzliche Daten anderer Tabellen ANGEZEIGT werden, sollen dort aber nicht gleichzeitig änderbar sein. Als Beispiel die Auswahl des Produktes in der Testreihe - da gibt es z.B. eine Kombobox, die den Namen des Produktes über eine Abfrage holt, die sich IN der Kombobox befindet und die ProduktID zurückliefert, aber den Namen für den Benutzer anzeigt. Gespeichert wird die ProduktID in der Testreihentabelle. So verwendet man mehrere Tabellen gleichzeitig, aber (in diesem Beispiel) wird nur die Testreihentabelle verändert. Die zugehörigen Tests befinden sich dann in einem Unterformular, das über die TestreihenID mit dem Hauptformular verbunden ist. Jeder neue Test gehört dann automatisch zur Testreihe. Beim Anzeigen sieht man im Hauptformular die Testreihe (und nur deren Daten sowie Daten aus Lookup-Tabellen wie den Produktnamen) und im Unterformular automatisch nur die passenden Tests. Also bearbeitet das Unterformular wiederum nur genau EINE Tabelle, die Testtabelle. Das gesamte Formular verwendet dagegen im Beispiel drei Tabellen.
Daher immer bedenken: Das Datenbankdesign der Tabellen soll Daten optimal organisieren, ohne auf spätere Verwendung zu achten. Das Formulardesign soll Daten von jeweils einer Tabelle bearbeitbar machen, ohne daß der Benutzer das genau weiß, wie die Datenbank dahinter aussieht. Das Berichtsdesign soll alle Daten zusammenführen und in optimaler Weise für den gewünschten Bericht zusammenstellen, ohne auf die Einschränkungen des Formulardesigns Rücksicht nehmen zu müssen. Redundanz ist hier kein Problem, auch Aufzählungsfelder auszugeben in einer Zeile ist kein Problem usw.

Gruß

Christian