Office: (Office 2007) Abfrage zu komplex (Laufzeitfehler 3360) -- Alternative gesucht

Klar gibt es eine effizientere Variante. Aber dazu müsste mal Butter bei die Fische. Kann sein, dass ich was übersehen habe, aber bisher weiß ich nur: Es gibt eine Rohdatentabelle und zu den Rohdaten sollen Kennzahlen ermittelt werden. Manchmal macht es Sinn, die Umstände der Realität darzustellen, damit für ein Problem eine Lösung gefunden werden kann.
Wenn alle Kennzahlen nach dem gleichen Schema ermittelt werden würden, könnte eine einzige Abfrage dafür ausreichen. Aber auch hier gilt: Normalisierung der Daten ist Voraussetzung.

 

Wie auch:

Wenn das Format der Ergebnisansicht im Mittelpunkt aller Betrachtung steht, sollte man besser in Excel arbeiten. Dort kann man einfacher über Kreuz und Quer Formeln erstellen. Womit sich dann auch die Frage stellt, warum man sich denn in Access (Datenbank) bewegt. Wegen der möglichen mehr Zeilen (größere Tabelle)?

Wenn man sich aber bewusst für Datenbank entscheidet, sollte man deren Stärken nutzen und deren Verarbeitungsmethoden und -logik einsetzen.

An Tabellenstrukturen lässt man da nicht sehr viele ran, schon mal, weil da steuerlich abzusegnende Prozesse ablaufen und da nicht beliebig von irgendjemand rumgedoktort werden darf, und der Ort für Ausprobier-Aktionen von Ahnungslosen ist das dann sicher auch nicht.
Man darf also davon ausgehen, dass Ausgaben Datenzusammenstellungen (Reports) sind, in denen wie bei Abfragen aus mehreren verknüpften Tabellen durch die Verknüpfung denormalisiert wurde.

Wenn Daten nur im Durchlauf verarbeitet werden und somit keine Haltung und Akkumulierung von Daten erfolgt und sich somit Fragen der Einhaltung der Datenintegrität nicht stellen, kann man in der Tat gerne auf Normalisierungsprozesse oder gar Datenmodellierung verzichten.

Interessanterweise wurde der Begriff AUFWAND verwendet. Normalisierung & Co. sind jetzt nicht theoretische Monster, um Neulinge zu ärgern und abzuschrecken, sondern sie sind die Umsetzung von Regeln, die darauf hinwirken, eine bessere Verarbeitbarkeit per SQL (native Sprache in Datenbanken) zu erreichen.
Jetzt stellt sich die Frage, wie die "originale" Struktur der SAP-Daten zu beurteilen ist. Es könnte sein, man legt einfach mit der Verarbeitung los und nimmt dafür Umständlichkeiten und Aufwand in der Verarbeitung in Kauf. Es könnte aber auch sein, man stellt zu Beginn auf besser verarbeitbare Strukturen um und kann dann effizient in der Verarbeitung sein.
Da wird man dann einen Aufwandsvergleich anstellen, wobei man aber hoffentlich so clever ist, auch mögliche Folgeauswertungen zu berücksichtigen.
Um es mit Eierkuchen zu sagen: Es könnte vorteilhaft sein, die Kalkschalen der Eier vor dem Teigrühren und Backen zu entfernen, also gleich eine verarbeitungs- und speisegerechte Umstrukturierung vorzunehmen.

Ahnungslos weitermachen ist da die logische Folgerung?
Man könnte aber auch die Finger davon lassen, oder aber, insbesondere wenn die Auswertungen eine gewisse Wichtigkeit in Ergebnis und terminlicher Bereitstellung haben, rechtzeitig in notwendige Qualifikation investieren.

Nicht zuletzt: Eine Lösung einer Aufgabe beginnt regelmäßig damit, dass man die Aufgabe versteht und vollständig formulieren kann. Eine sinnhafte Aufgabenformulierung kann ja in Anteilen schon die Handlungsanweisung zur Lösung sein.
Kennzahlen aus SAP-Daten ist da etwas dünn. So viele Würfel hat man gar nicht im Haus, um da einigermaßen einige Faktoren zu berücksichtigen.

 

Hi zusammen,
vielen Dank für die ausführlichen Rückmeldungen. Ich habe zuerst einmal den ersten Vorschlag von markusxy aus Beitrag #2 versucht umzusetzen.

Das hat einige Zeit in Anspruch genommen. Leider führt dies in Summe zum exakt gleichen Fehlerbild. Funktioniert also leider nicht.

Der Vorschlag aus #13 mittels einer VBA-Anweisung ist für mich wahrscheinlich erstmal nicht so schnell umzusetzen.

gruss ekkehard

Ich bin ganz ehrlich. Ich verstehe den Code nicht. VBA ist für mich vollkommen unbekannt, zumindest in dieser Schwierigkeitsstufe. Berichte öffnen mittels Button und VBA bekomme ich noch hin, sowas leider nicht. Ich danke Dir natürlich trotzdem für das Beispiel. Ich werd mich auf jeden Fall am Mittwoch damit auseinandersetzen, sobald ich wieder Zugriff auf die Datenbank habe. Eventuell kann ich mich beim Ausprobieren damit eher vertraut machen.

Ich habe in diesem Fall über den SAP-Tabellenbrowser vollen Lesezugriff auf alle SAP-Tabellen. Ich gehe daher mal davon aus, dass es keine denormalisierten Tabellen sind.

Ja genau das ist bei mir genau so der Fall. Die Datenbank dient nicht als Datenhaltungssystem sondern wirklich nur zum täglichen erzeugen von Kennzahlen in etwas effizienterer Form als es Excel durchführt.

Mir ist jetzt noch eine Möglichkeit eingefallen, wie ich zur Lösung kommen kann. Austesten kann ich das leider erst wieder am Mittwoch da meine studentischen Arbeitszeiten Mi/Do sind.

Idee:
Bisher: 1 Abfrage, die einen INSERT INTO für ALLE Kennzahlen beinhaltet. Funktioniert nicht wegen zu kompelx

Neue Idee: Ich baue in JEDER Abfrage welche je eine Kennzahl berechnet, einen INSERT INTO ein. Somit bleibt die Komplexität einer einzigen Abfrage stets gering. DANN baue ich einen Button und hinterlege einen SQL-Befehl, der quasi ALLE Abfragen startet

z. B. könnte der Code einer Kennzahlenabfrage (Abfrage1) folgendermaßen aussehen:

Code:

Somit wäre die Abfrage relativ einfach und auch gewährleistet, dass die Kennzahl immer im richtigen Datensatz angefügt wird (letzte Codezeile).

Dem Button, welcher alle Abfragen starten soll, würde ich dann folgenden VBA-Code hinterlegen:

Code:

Das wäre jetzt noch etwas was mir eingefallen ist und eventuell die Lösung bieten könnte.

Gruß Chris

 

Hallo Chris,
Das ist im Prinzip nix anderes als mein Code und geht auch in einer Schleife.
Code:

gruss ekkehard

 

Nö. Daten anfügen kann nicht zu komplex sein. Wohl aber deren Ermittlung in der verwendeten Fassung. Ich würde mich auch wehren, einen Haufen Sand in der Form umzusetzen, dass man jedes Sandkorn zwischen die Fingerspitzen nimmt, zumal wenn da ein Bagger daneben steht ...

Jo. Siehe Access-Spezifikationen.

 

gruss ekkehard

Moin,

das mit der Schleife habe ich hinbekommen. Funktioniert einwandfrei mit Dummies. Jetzt habe ich nur noch ein Problem. Der aktualisierte INSERT INTO Befehl klappt nicht wie ich mir das vorstelle

Code:

Das soll jetzt quasi gewährleisten, dass der Wert in die Spalte Umbuchung_Lager1 der Tabelle "Kennzahlen" eingefügt wird. in VALUES habe ich einfach den SELECT reingepackt der quasi die Kennzahl berechnet. Die letzte Codezeile soll gewährleisten, dass die Kennzahl immer im richtigen Datensatz angefügt wird und nicht jedesmal einen neuen Datensatz erzeugt.

Was ist an dem Code falsch?

Fehlermeldung: Syntaxfehler in Abfrageausdruck (SELECT .......)

 

Siehe: INSERT INTO-Anweisung

 

Ah ok danke! Geht also nicht mit INSERT INTO. Habe die UPDATE genommen. Kriege das mit der Syntax aber auch nicht hin. Der will jedesmal das ich einen Parameter eingebe. Wenn ich einen eingebe, passiert nichts.


Code:

 

Code:

2 Where-Klauseln sind zu viel, häng sie mit AND aneinander.

 

2 Where-Klauseln sind zu viel, häng sie mit AND aneinander.

Hatte ich auch erst so gemacht. Ging ebenfalls nicht.

Zudem ist die erste WHERE-Klausel ja zur Berechnung der Kennzahl da (die wiederum über die UPDATE-Funktion in der Tabelle angefügt werden soll. Der zweite WHERE-Teil ist Teil der UPDATE Funktion. Das kann ich doch nicht mit AND verbinden? Immerhin handelt es sich ja um eine Verschachtelung.

 

Ich brauche eine neue Brille :-(

Ansonsten ist es aber wenig hilfreich, wenn Du die Fehlermeldung nicht benennst, das ist nämlich kein Syntaxfehler, sondern ein fehlender Parameter. Der fehlt, weil es in der Updateklausel keine Tabelle Rohdatentabelle gibt (und nicht geben kann):
Code:

Abhilfe könnte eine Update-View aus Kennzahlen und Rohdatentabelle schaffen, das überblicke ich aber mangels Daten und Semantik nicht.

 

Code:

Den Text kannst Du am ersten & zusammenkleben und auch die Leerzeichen reduzieren- dient nur der Lesbarkeit hier im Form.

Sinnvollerweise würde man das Datum wissen wollen, um nicht immer alle Datensätze zu aktualisieren.

 

Hi Nouba,

vielen Dank für Deinen Tipp! Der Code funktioniert, nur leider habe ich damit ein ziemlich großes Problem: Ich habe über 80 Abfragen. Das funktioniert leider nicht so ohne Weiteres da mir der nötige Hintergrund an SQL/VBA fehlt.

Für mich wäre es ideal, wenn ich meine Logik nach der ich die Abfragen aufgebaut habe, irgendwie erhalten kann.

also z. B.:

Code:

Einige Abfragen sind noch deutlich komplexer, nur würde ich ungerne diese Abfragen zur Kennzahlberechnung wieder komplett ummodeln.

Am schönsten wäre es, wenn ich um diesen Code quasi nur etwas "drum herum basteln" müsste, sodass er mir das in meine blöde Tabelle hinzufügt. Ich hab jetzt nochmal auf die Schnelle ein kleines schönes Bild gemacht, falls es noch nicht ganz klar sein sollte was mein Ziel ist..

Ich versteh es einfach nicht was daran so schwer sein kann aus einem 1-spaltigen 1-zeiligen Abfrageergebnis eine Zeile zu machen.... Rein optisch ist das total banal. Ich verzweifel an dieser Hürde langsam....

Zum Bild: Oben sind 3 Beispielabfragen die JEWEILS eine Kennzahl berechnen (Code und so wie es dann letztlich angezeigt wird). Unten ist die Kennzahlentabelle die zu einem Datum die Kennzaheln hinzufügen soll Das Datum steht schon in der Tabelle. Es muss alles nur irgendwie in diesen DAtensatz rein. Vielleicht hat ja doch noch jemand eine super Idee die mir relativ einfach weiterhelfen kann *frown.gif*




Danke schonmal und noch einen schönen Abend.


Gruß Chris

 

Mache Dich zum Thema Kreuztabellenabfrage schlau - und dann legst Du die Daten normalisiert an, oder wertest die Rohdaten im Idealfall einfach nur mit einer Abfrage, bzw. mit je einer Abfrage je Thema aus.

PS: wenn ein Auszug der Rohdaten (natürlich anonymisiert) vorläge und bekannt wäre, was daraus ausgewertet werden soll, könnte man konkrete Vorschläge machen.

 

Guten Morgen,

es geht einfach um normale Materialbewegungsdaten zu denen tagesweise Kennzahlen erfasst warden. Jeder Datensatz ist ein Transport der Dinge wie Von->Nach, Datum, Uhrzeit, Was transportiert wurde usw. enthält.

Habe jetzt eine Lösung gefunden die wahrscheinlich auch "datenbankfreundlicher ist". Ich mache es wie ich eingangs in #1 beschrieben hatte mit dem Insert Into, nur mit dem Unterschied, dass ich jetzt für jede "Kennzahlengruppe" eine Tabelle erstelle (z. B. für Umlagerungen die Tabelle Kennzahl_Umlagerungen) und dann die Kennzahlen über mehrere Tabellen verteile. Die verknüpfe ich einfach über das Datum mit einer 1:1 Beziehung fertig ist die Sache. Bisher funktioniert es :-)