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

Guten morgen zusammen,

ich versuche gerade aus ca. 80 Abfragen einen Datensatz zu generieren. Jede Abfrage berechnet eine Kennzahl. Mit der nun benötigten Abfrage möchte ich aus allen Kennzahlen einen Datensatz generieren. Bis gerade hat das noch super geklappt, nur jetzt bringt er Laufzeitfehler 3360 (Die Berechnungslaufzeit war bis soeben aber nichtmal 0,5 Sekunden).

Code:

Ich habe den Code mal von der Systematik her angeführt. Ich fand die Lösung relative easy und die Berechnungslaufzeiten waren super bisher (ca. 40 Kennzahlen sind schon drin). Nur jetzt will er leider nicht mehr weiterrechnen.

Hat jemand eine Idee?

Vielen Dank schonmal und beste Grüße *mrcool

:)

 

Du kannst die Aktion ja aufteilen.
Einen Teil per Insert, einen Teil per Update.

Kann es sein, dass die Daten nicht normalisiert sind, wie es in einer Datenbank sein sollte, sondern Excel mäßig.
Das zieht dann immer einen Rattenschwanz an Problemen nach sich.

 

Gute Frage. Die Daten kommen direkt aus einer SAP-Abfrage. Da das ja auch eine Datenbank ist, gehe ich einfach als Laie mal davon aus das die normalisiert sind. Korrigiere mich wenn ich mit der Vermutung total daneben liege.

Mit dem Aufteilen könnte ich mal probieren. Da ich aktuell aber noch nicht ganz bei der Hälfte bin und in Summe sogar noch weitere Kennzahlen dazukommen können. bin ich nur unsicher ob das der Schlüssel zum Erfolg ist. Kann ja eigentlich nicht sein das Access da schlapp macht. Ich meine, es sind zwar "relative" viele Abfragen die da zusammengeführt werden, aber das sind richtige Pipifax-Abfragen.

Hier ein verallgemeinertes Beispiel

Code:

 

Ich liebe das Vervielfältigen von SAP-Daten. Das muss ja auch eine außerordentlich schlechte Datenbank sein, wenn man sich diesem Thema zugeneigt fühlt.

PS: wenn ich Dein Chef wäre, würde ich Dir empfehlen, Dich auf die Kernaufgaben Deines Beschäftigungsverhältnisses zu konzentrieren, das vermutlich ein anderes ist, als (unnötig) Access-Datenbanken zu entwickeln.

 

Sowas gehört natürlich niemals zu den Kernaufgaben in einer Fachabteilung. i.d.R. macht das auch niemand weil dazu einfach die Zeit fehlt. Ich bin aber ein Student der 1 Tag pro Woche dort arbeitet, für verhältnismäßig wenig Geld und das Thema sogar vorgeschlagen hat. Die gegenwärtige Lösung ist absolut keine Alternative. Einen SAP-Report programmieren zu lassen ebenso nicht. Auch wenn es eine interne IT gibt die das programmieren könnte, würde es dennoch a) zu kostenintensiv werden und b) zu viel Zeit kosten bis es dann endlich mal umgesetzt ist. Der Workload in der IT eines Großkonzerns wo an allen Ecken und Enden automatisiert wird, ist sehr hoch. Da landet ein SAP-Report für eine Fachabteilung weit weit unten in der Prioliste. Das Änderungsmanagement wenn sich an den eigenen Prozessen was verändert ist ebenfalls nicht so einfach zu realisieren. Es müsste jedesmal wieder zur Problemlösung ausgelagert werden weil die eigene Abteilung das nicht lösen kann oder gar nicht darf. Das Berechtigungsmanagement in großen Firmen ist auch eine Sache für sich.

Das Denken in Absolutismen ist zudem oft in der Praxis nicht so sonderlich förderlich. Es ist meist nicht die Ideallösung umsetzbar. Ist einfach so. Die Access Lösung ist für alle Beteiligte der beste Mittelweg.

So viel zum Exkurs :-)

 

Der Ansatz, Felder mit sich wiederholenden Kennzahldaten zu führen, verletzt die Regeln der Normalform und lässt spätestens dann Frust aufkommen, wenn sich am Kennzahlgefüge etwas ändert.

 

Das ist jetzt zwar nicht relevant für das Posting-Thema, aber ich versuche es Dir mal kurz zu erläutern:

Es handelt sich nicht um eine typische Datenbank wie das vielleicht der Datenbanker verstehen würde. Es dient einfach zur Erleichterung der täglichen Kennzahlenprozesse. Wenn das wirklich sauber nach den Regeln der Datenbankmodellierung aufgezogen werden soll, dann wäre der Aufwand zu hoch. Hier kennt sich zudem auch keiner damit aus.

Fest steht zumindest. Die DB ist wartungsfreundlich. Alles was bisher erzeugt wurde, lässt sich easy abändern. Das Problem was ich eingangs beschrieben habe handelt ja davon, dass alle Kennzahlen einem Datensatz zu einem zugehörigen Datum angefügt werden. Aus dieser Zieltabelle nenne ich sie mal, will ich im Anschluss ein Endlosformular erzeugen. Hinter jedem Datensatz wird ein Button platziert sein. Wenn ich den Button drücke, wird ein Bericht erzeugt (mit Grafiken usw.)

Das ganze Konstrukt (ich nenne es lieber nicht mehr Datenbank um Euch nicht zum Kochen zu bringen *biggrin.gif*) hat gar nicht den Anspruch so zu sein wie eine z. B. Kundendatenbank bei OTTO Versand aufgebaut sein müsste

 

Code:

Dir ist schon klar, dass du damit ein Kreuzprodukt erzeugst?
Also alle Datensätze aus Rohdatendatentabelle * Abfrage1 * Abfrage2 * Abfrage3 *** Abfrage80
Wäre es nicht vielleicht sinnvoll, sie alle mit der Rohdaten-Tabelle zu verjoinen?

Auch wenn es keine echte Datenbank sein soll, kann ich mir vorstellen, dass es sich irgendwann rächen wird, nicht normalisiert zu haben. Vielleicht ist es sogar jetzt schon der Fall.

 

Dir ist schon klar, dass du damit ein Kreuzprodukt erzeugst?

OK, das war mir nicht jetzt nicht bewusst. Ich dachte, ich füge einfach nur Werte aus einzelnen Abfragen in einzelne Zellen ein. Das mit dem Kreuzprodukt macht es doch etwas kompliziert.

Gibt es denn eine "effizientere" Variante, aus x Abfrageergebnissen (die jeweils nur einen Wert liefern) einen Datensatz zu generieren?

 

Das macht man nur, wenn man es so braucht.
Was du brauchst ist uns allerdings nicht klar, deshalb macht es auch keine Sinn sich Gedanken zu machen.

 

Hatte ich ja bereits oben geschrieben:

Ich habe eine Zieltabelle mit fixem Aufbau an Spalten. 1 Datensatz enthält alle Kennzahlen eines Datums. Ich habe x Abfragen die jeweils eine Zahl im Ergebnis haben. Dieses Ergebnis soll dem richtigen Attribut zum zugehörigen Datum zugefügt werden. Bisher hat das alles so gut funktioniert

 

Du hast auch im ersten Kommentar eine funktionierende Lösung erhalten.
Hast du das umgesetzt?

Die restlichen Kommentare stellen ja nur fest, dass das Konstrukt nicht Datenbankkonform ist.
Das spielt nur dann eine Rolle, wenn die Ergebnisse wiederum per Abfragen/Report/Form usw. weiterverarbeitet werden.

 

Hallo,
Warum nicht Markus' erstem Vorschlag folgen?
Ich würde es mit einer Schleife abarbeiten.
Luftcode:
Code:

gruss ekkehard

 

Einen Hühnerstall kann man auch auf Sand aufsetzen. Wenn Du den aber zu einem Elfgeschosser umbauen willst, wirst Du auf dem Wege Probleme bekommen - weil für ein richtiges Vorhaben muss man ein ausreichendes Fundament setzen.

Code:

Das zweite nennt sich Massendatenverarbeitung (alle Anzahlen auf einmal). Dafür sind SQL-Anweisungen konzipiert, siehe auch Grundlagen - SQL ist leicht (0) - Vorspiel

 

\@ekkehard,
womöglich reicht sogar eine einzige Abfrage.
Aber wie gesagt, es macht keinen Sinn nachzudenken, so lange die Details unklar sind.