Unvollständige Abfrage

[H_Stadler]

Hallo zusammen,

Leider habe ich ein Problem mit meiner Abfrage. Die Abfrage bezieht sich auf eine sehr große Tabelle (tbl_Maengelliste) und soll alle DS wiedergeben. Dies ist nicht der Fall. Ich habe versucht bei allen Feldern das Kriterium

Code [Auswählen] Erweitern

Ist Null ODER Ist nicht Null bzw.

Code [Auswählen] Erweitern

Wie "*" anzugeben. Leider stürtzt Access dabei ab. Ich gehe davon aus, dass es sich einfach um zu viele Felder/Kriterien handelt.

Hier der SQL Code meiner Abfrage (Fühlt euch bitte nicht erschlagen, die DB Struktur hätte ich gerne anders aufgebaut, aber es soll "alles" in einer Tabelle stehen, damit die Tabelle nach Bedarf zu Excel importiert werden kann)

Code [Auswählen] Erweitern

SELECT tbl_Maengelliste.MängelID, tbl_Prüffeld.Prüffeld, tbl_Maengelliste.SchaltanlagenSerienNr, tbl_Maengelliste.Workorder, tbl_Maengelliste.KomissionsNr, tbl_Maengelliste.GesamtSerienNr, tbl_Anlagentyp.Anlagentyp, tbl_Schranktyp.Schranktyp, tbl_Kunden.Kunde, tbl_Maengelliste.Anlagenkennung, tbl_Maengelliste.Standort, tbl_Maengelliste.Land, tbl_Abteilung.AbteilungsName, tbl_Mitarbeiter.MitarbeiterName, tbl_Abteilung_1.AbteilungsName, tbl_Mitarbeiter_1.MitarbeiterName, tbl_Mitarbeiter_1.MitarbeiterName, tbl_Abteilung_2.AbteilungsName, tbl_Mitarbeiter_2.MitarbeiterName, tbl_Abteilung_3.AbteilungsName, tbl_Mitarbeiter_3.MitarbeiterName, tbl_Maengelliste.DatumPrüfbeginn, tbl_Maengelliste.DatumPrüfende, tbl_Maengelliste.ÜbertragenDurch, tbl_Maengelliste.QAATRZeit, tbl_Maengelliste.ATRNr, tbl_Maengelliste.Fehlerbeschreibung, tbl_Maengelliste.Ort, tbl_Maengelliste.BMK, tbl_Fehlerart.Fehlerart, tbl_Maengelliste.FestgestelltDatum, tbl_Abteilung_4.AbteilungsName, tbl_Mitarbeiter_4.MitarbeiterName, tbl_Abteilung_5.AbteilungsName, tbl_Anlagenstatus.Anlagenstatus, tbl_Maengelliste.BehobenDatum, tbl_Abteilung_6.AbteilungsName, tbl_Mitarbeiter_5.MitarbeiterName, tbl_Maengelliste.ATRZeit, tbl_Maengelliste.ÜberprüftDatum, tbl_Abteilung_7.AbteilungsName, tbl_Mitarbeiter_6.MitarbeiterName
FROM tbl_Schranktyp INNER JOIN (tbl_Prüffeld INNER JOIN (tbl_Kunden INNER JOIN (tbl_Fehlerart INNER JOIN (tbl_Anlagentyp INNER JOIN (tbl_Anlagenstatus INNER JOIN ((tbl_Abteilung INNER JOIN (tbl_Mitarbeiter AS tbl_Mitarbeiter_6 INNER JOIN (tbl_Abteilung AS tbl_Abteilung_7 INNER JOIN (tbl_Mitarbeiter AS tbl_Mitarbeiter_5 INNER JOIN (tbl_Abteilung AS tbl_Abteilung_6 INNER JOIN (tbl_Abteilung AS tbl_Abteilung_5 INNER JOIN (tbl_Mitarbeiter AS tbl_Mitarbeiter_4 INNER JOIN (tbl_Abteilung AS tbl_Abteilung_4 INNER JOIN (tbl_Mitarbeiter AS tbl_Mitarbeiter_3 INNER JOIN (tbl_Abteilung AS tbl_Abteilung_3 INNER JOIN (tbl_Mitarbeiter AS tbl_Mitarbeiter_2 INNER JOIN (tbl_Abteilung AS tbl_Abteilung_2 INNER JOIN (tbl_Mitarbeiter AS tbl_Mitarbeiter_1 INNER JOIN (tbl_Abteilung AS tbl_Abteilung_1 INNER JOIN tbl_Maengelliste ON tbl_Abteilung_1.AbteilungsID = tbl_Maengelliste.VPAbteilung) ON tbl_Mitarbeiter_1.MitarbeiterID = tbl_Maengelliste.VPServicemonteur) ON tbl_Abteilung_2.AbteilungsID = tbl_Maengelliste.HPAbteilung) ON tbl_Mitarbeiter_2.MitarbeiterID = tbl_Maengelliste.HPServicemonteur) ON tbl_Abteilung_3.AbteilungsID = tbl_Maengelliste.FIFCAbteilung) ON tbl_Mitarbeiter_3.MitarbeiterID = tbl_Maengelliste.FIFCServicemonteur) ON tbl_Abteilung_4.AbteilungsID = tbl_Maengelliste.FestgestelltAbteilung) ON tbl_Mitarbeiter_4.MitarbeiterID = tbl_Maengelliste.FestgestelltName) ON tbl_Abteilung_5.AbteilungsID = tbl_Maengelliste.ZuBehebenAbteilung) ON tbl_Abteilung_6.AbteilungsID = tbl_Maengelliste.BehobenAbteilung) ON tbl_Mitarbeiter_5.MitarbeiterID = tbl_Maengelliste.BehobenName) ON tbl_Abteilung_7.AbteilungsID = tbl_Maengelliste.ÜberprüftAbteilung) ON tbl_Mitarbeiter_6.MitarbeiterID = tbl_Maengelliste.ÜberprüftName) ON tbl_Abteilung.AbteilungsID = tbl_Maengelliste.SachbearbeiterAbteilung) INNER JOIN tbl_Mitarbeiter ON (tbl_Mitarbeiter.MitarbeiterID = tbl_Maengelliste.SachbearbeiterName) AND (tbl_Abteilung.AbteilungsID = tbl_Mitarbeiter.AbteilungsIDRef)) ON tbl_Anlagenstatus.AnlagenstatusID = tbl_Maengelliste.AnlagenstatusIDRef) ON tbl_Anlagentyp.AnlagentypID = tbl_Maengelliste.AnlagentypIDRef) ON tbl_Fehlerart.FehlerartID = tbl_Maengelliste.FehlerartIDRef) ON tbl_Kunden.KundeID = tbl_Maengelliste.KundeIDRef) ON (tbl_Prüffeld.PrüffeldID = tbl_Maengelliste.PrüffeldIDRef) AND (tbl_Prüffeld.PrüffeldID = tbl_Fehlerart.PrüffeldIDRef) AND (tbl_Prüffeld.PrüffeldID = tbl_Anlagentyp.PrüffeldIDRef)) ON tbl_Schranktyp.SchranktypID = tbl_Maengelliste.SchranktypIDRef
WHERE (((tbl_Mitarbeiter_5.MitarbeiterName) Is Null Or (tbl_Mitarbeiter_5.MitarbeiterName) Is Not Null));


Gibt es noch eine andere Möglichkeit für mich die Abfrage vollständig anzeigen zu lassen? Sprich auch mit Datensätzen, in denen es leere Felder gibt?

[el_gomero]

Hallo,

(Fühlt euch bitte nicht erschlagen, die DB Struktur hätte ich gerne anders aufgebaut, aber es soll "alles" in einer Tabelle stehen, damit die Tabelle nach Bedarf zu Excel importiert werden kann)

Das ist doch absoluter Murks. Eine db gehört nach den Regeln der Normalisierung in ein ordentliches Datenmodell gepackt und aufgebaut. Der Export nach Excel ist damit auch kein Problem.

Die entstehenden Probleme liegen wahrscheinlich in den InnerJoins begründet (müssten dann wohl LeftJoins sein) und treten bei einem vernünftigen Datenmodell nicht auf.

[H_Stadler]

Danke für die freundliche Rückmeldung!

[el_gomero]

keine Ursache!

[DF6GL]

Hallo,

Das ist doch absoluter Murks.

kann ich nur bestätigen...  jedoch nicht, dass die Rückmeldung unfreundlich ist...  Unfreundlich ist, diesen Weg ernsthaft weiter zu  unterstützen, weil diese Methodik (deren Sinn nicht erkennbar ist) nicht zielführend oder erfolgsversprechend ist...

[H_Stadler]

Konstruktives Feedback kenne ich allerdings auch anders. Schließlich bin ich hier nicht ohne Grund als "Hilfesuchender" unterwegs... 3 Wochen Access Erfahrung machen niemanden zum Profi. Für den Hinweis, dass mein Aufbau falsch ist bin ich dankbar, aber "Murks" ist wenn ich Mist backe und euch den als Kuchen verkaufe 

Ich habe nunmal ein super Tutorial gefunden, dass den Excel Export mit VBA deutlich vereinfacht. Da aber noch ausreichend Wissenslücken bestehen, kann ich so etwas zunächst nur in der Form umsetzen in der es erklärt wird. Sprich mit einer Tabelle. Bisher bin ich noch auf keine Probleme gestoßen, auch wenn ich geahnt habe, dass die Normalisierungsregeln nicht alle eingehalten wurden. Sollte ich hier mit mehreren Unterformularen arbeiten bekomme ich aber den Excel Export via VBA nicht mehr hin.

[DF6GL]

Hallo,

es ist nur die Methode mit und an der DB  bewertet, nicht Deine Person...

Welchen Sinn hat es,  aus einer mehr oder weniger normalisierten DB sämtliche Felder und Datensätze nach Excel zu exportieren?
 
Vermutlich werden durch die Menge der selektierten Felder die Access-Spezifikationen gesprengt.

Und das ist auch durch Trickserei nicht zu verhindern.


die Anzeige "leerer" DS ist hier (wie erwähnt) nur (sinnvoll) über die Left-, bzw. Right-Join Verknüpfung zu erreichen und nicht über einen Where-Condition-Ausdruck.

Sollte ich hier mit mehreren Unterformularen arbeiten bekomme ich aber den Excel Export via VBA nicht mehr hin.

Was hat das mit UFOs zu tun? Und was genau klappt via VBA (Code) nicht mehr?

[bahasu]

Hi,

den Export nach Excel kannst Du statt aus EINER Tabelle auch aus EINER Abfrage realisieren.

In dieser Abfrage kannst Du dann Tabellen mit einander verknüpfen. Durch das Aufteilen der Daten auf verschiedene Tabellen hast Du für die Normalisierung gesorgt.

Insofern ist es besser, erst über das Datenmodell nachzudenken (es wird hier bestimmt auch dafür Tipps geben) und erst danach den Export angehen. Ohne Normalisierung kann es ansonsten später zu vielen Probleme führen.

Harald

[H_Stadler]

Hallo nochmal,

es ist nur die Methode mit und an der DB  bewertet, nicht Deine Person...

Dessen bin ich mir bewusst. Hat mich nur geärgert, weil das bereits mein zweiter Versuch ist diese Datenbank auf die Beine zu stellen. Ich habe Tage lang nach bestem Wissen und Gewissen daran gearbeitet und ein unverblühmtes "Murks" ist dann sozusagen ziemlich unfair einem Anfänger gegenüber...

Der Sinn das ganze nach Excel zu exportieren ist, dass die Daten in Excel analysiert werden sollen. Es sollen also Graphen erstellt werden, die Laufzeiten etc. darstellen. Das ist letztlich das Ziel des Exports.

Was hat das mit UFOs zu tun? Und was genau klappt via VBA (Code) nicht mehr?

Ich glaube, dass ich mit UFOs arbeiten muss, wenn ich meine zu große (und nicht normalisierte) DB aufteile. Letztlich meine ich damit, dass ich nicht weiß wie ich das in VBA regeln muss, dass mehrere Tabellen aus Access als ein Worksheet nach Excel exportiert werden können. Aus dem Grund habe ich auch versucht eine große Tabelle statt mehrerer kleiner anzulegen.

Insofern ist es besser, erst über das Datenmodell nachzudenken (es wird hier bestimmt auch dafür Tipps geben) und erst danach den Export angehen. Ohne Normalisierung kann es ansonsten später zu vielen Probleme führen.

Genau das mache ich jetzt auch. Sollte ich damit nicht weiterkommen wende ich mich nochmal an euch.

[el_gomero]

Zitat von: bahasu am Heute um 14:30:37
Insofern ist es besser, erst über das Datenmodell nachzudenken (es wird hier bestimmt auch dafür Tipps geben) und erst danach den Export angehen. Ohne Normalisierung kann es ansonsten später zu vielen Probleme führen.
Zitatende bahasu:

Genau das mache ich jetzt auch. Sollte ich damit nicht weiterkommen wende ich mich nochmal an euch.

Ganau das hatte ich in meiner ersten Antwort bereits empfohlen. Und wenn es beim Datenmodell klemmt wirst du hier geholfen

Schönes WE

[DF6GL]

Hallo,

Der Sinn das ganze nach Excel zu exportieren ist, dass die Daten in Excel analysiert werden sollen

Das ist ok, nur dazu braucht man nicht die gesamten Tabelleninhalte zu exportieren. Es reicht, sich auf die darzustellenden Daten zu beschränken, und das wären deutlich weniger als der gesamte DB-Inhalt.

[ebs17]

Leider stürtzt Access dabei ab. Ich gehe davon aus, dass es sich einfach um zu viele Felder/Kriterien handelt.

Konkret: 20 INNER JOIN's sind mehr als die in Jet-SQL zulässige Anzahl von Verknüpfungen in einer Abfrage von 16.
Siehe auch Access 2010-Spezifikationen.

Auf den einzig sinnvollen Weg würdest Du schon hingewiesen.

[H_Stadler]

Guten Morgen allerseits,

Ich bleibe mal in diesem Thread und bitte euch mal über meinen neuen DB Aufbau zu gucken. Ich habe jetzt nochmal alles neu aufgebaut, bin mir aber immer noch nicht sicher, ob ich alle Normalisierungsregeln berücksichtigt habe.

In den beiden Screenshots seht ihr einmal meinen neuen Aufbau und einmal das Formular zu Eingabe, damit ihr eine Vorstellung davon habt, was überhaupt gemacht werden soll.

Macht es Sinn mit den ganzen Beziehungen zu Feldern wie "SachbearbeiterIDRef" etc. zu arbeiten oder sollte ich diese Referenz Felder einfach löschen und dann im Formular die eigentlichen Felder der Sachbearbeiter Tabelle nutzen?

Freue mich über ein paar Tipps/Verbesserungsvorschläge!

Guten Start in die neue Woche 

[DF6GL]

Hallo,

an den Beziehungen hapert es noch ordentlich...

Ein Formular brauchst Du erst dann entwerfen, wenn die Tabellenstruktur vollständig und stimmig ist.

Unklar ist der Sinn der Tabellen tbl_Prüffeld und tbl_Abteilungen. Gibt es mehrere Prüffelder, die Anlagen betreuen und warum ist das Prüffeld keine Abteilung? Die daran geknüpften Beziehungen sind auch nicht (von mir) nachvollziehbar.

Die Tabellen in der "zweiten" Spalte"  können allesamt  zu einer ("tbl_Personen"  oder ähnlich) zusammengeführt werden, erforderlich ist dann noch eine Unterscheidung durch einen "Bearbeitertyp" (Sachbearbeiter oder Service oder...)


Was ist der Unterschied der einzelnen Servicemonteure(-Tabellen) ?  Wenn damit Monteure unterschiedlicher Hersteller (der Anlagen) gemeint sind, so fehlt eine Tabelle "tbl_Hersteller" , die ebenfalls mit tbl_Personen zu verbinden ist.


Die Auflistungs-Felder ATRNrx aus tbl_Maengelliste sollten auch in eine separate Tabelle ausgelagert werden.

Bei Anlagentyp und Schranktyp ist auf evtl. Abhängigkeit zu prüfen.

Macht es Sinn mit den ganzen Beziehungen zu Feldern wie "SachbearbeiterIDRef" etc. zu arbeiten

Ja, wobei das oben Gesagte Anwendung finden sollte (muss).

oder sollte ich diese Referenz Felder einfach löschen und dann im Formular die eigentlichen Felder der Sachbearbeiter Tabelle nutzen?

Nein!
Wobei die Frage obsolet erscheint, wenn die Tabellen zu einer zusammengefasst sind.


(ohne Gewähr auf Vollständigkeit ;-)  )

[H_Stadler]

Hallo,

Danke für das Feedback!

Unklar ist der Sinn der Tabellen tbl_Prüffeld und tbl_Abteilungen. Gibt es mehrere Prüffelder, die Anlagen betreuen und warum ist das Prüffeld keine Abteilung? Die daran geknüpften Beziehungen sind auch nicht (von mir) nachvollziehbar

tbl_Prüffeld beinhaltet zwei verschiedene Prüffelder über die die Anlagen laufen können. Je nach Prüffeld werden andere Anlagentypen genutzt und andere Fehlerarten festgestellt. Daher die Tabelle Prüfungen mit entspr. Beziehungen.
tbl_Abteilung beinhaltet 12 versch. Abteilungen in denen ein Mitarbeiter tätig sein kann (Fertigung, Service etc.). Die Hauptaufgabe dieser Tabelle ist es die Mitarbeiter filtern zu können, damit die Auswahl der Mitarbeiter in einer Kombobox leichter fällt.

Die Tabellen in der "zweiten" Spalte"  können allesamt  zu einer ("tbl_Personen"  oder ähnlich) zusammengeführt werden, erforderlich ist dann noch eine Unterscheidung durch einen "Bearbeitertyp" (Sachbearbeiter oder Service oder...)

Das Problem hierbei ist allerdings, dass ich bei meinem ersten Versuch tatsächlich eine Tabelle "Mitarbeiter" hatte und mehrere Beziehungen gezogen habe. Dadurch bekam ich dann aber in der Abfrage sämtliche "Inner Joins" (s.o). Ich ging davon aus, dass das die Probleme verursacht hat. Oder ist eine tbl_Mitarbeiter dann doch der richtige Weg?
Die unterschiedlichen Servicemonteure stellen lediglich Mitarbeiter in versch. Arbeitsschritten dar (HP=Hauptprüfung etc.).

Was mir hier Schwierigkeiten macht ist die Tatsache, dass viele Felder abhängig sind, also vorgefiltert werden sollen. Also alle Mitarbeiter sollen nach Abteilung vorgefiltert werden, Anlagentyp und Fehlerarten sollen nach Prüffeld vorgefiltert werden. Das macht es mit den Beziehungen nicht leicht...