Office: (Office 2007) geht die auch schneller?

Hallo Spezialisten,
ich habe hier diese schöne function, leider bei großeren Datenmengen uuh langsam,.....langsam.
Wie bekomme ich ein schnelleres Gesamt ergebniss hin.

?kann mann nicht den gesamtdatensatz in ein recordset laden, mit einem weitern RS2 im RS1 die daten zusammenfassen , und dann zum abgefragten Krit das ergebniss liefern?!?!?

wirds daduch schneller?

wie? mache ich es dann?
schränkt dann wohl die möglichkeit bei einer Qurery ,dann aus!?

Grüße & Danke Olaf


Code:

:)

 

Gibt es einen passenden Index in der Tabelle?
Zumindest ein Index über das Feld von Krit_IDNAME sollte helfen.
Noch besser wäre ein 2-Felder Index über Krit_IDNAME und Krit_SpaltenName.
Wobei is not null vom Jet-Abfrageoptimierer vermutlich nicht mit einem Index-Seek versehen wird. feld > '' bei einem Textfeld bzw. feld > [kleinstmöglicherWert] ist dem Jet-Abfrageoptimierer lieber.

BTW: Group By Krit_IDNAME ist ziemlich umsonst, da nur ein Wert vorkommen kann.


Such auch einmal nach ConcatVar von Michael Zimmermann.

 

Hallo Josef,

Indexe und is not null sind sicher gestellt, hilft leider nicht.
Was hälst Du von meiner idee geht das überhaupt?

Danke
Olaf

 

Wast ist denn das gewünschte Ziel der Übung?
Evtl. hilft Dir DLookUp bzw. die alternative TLookUp von Sascha weiter.

 

Ich verstehe nicht, wo in der gezeigten Prozedur ein zweites Recordset helfen soll.

 

Hallo,
allso das ziel ist es bei 20t Datensätzen bei ca 1200 St KDnr einen schnelleres end ergebniss herzustellen.
Wartezeit jetzt ca 10min und gefühlte ehwig minuten. *grins , nein ich muss das jeden Tag wiederholen deswegen.

Nun meine Idee ist es ein RS solange offen zuhalten bis alle KD sätze durch sind, müßte doch schneller sein oder?

Mist wenn ichs doch besser verballisieren könnte *mad.gif*

Ich mein wenn ich das wie heute mache Query mit den Grup KDNR öffnet dann 1200 mal die 20t DB das ist doch das Zeitliche problem.

kann ich nicht die DB mit den 20t DS einmal öffnen und mit einem 2 RS oder sonstigem..... die KD DB und übergbe.

Und jetzt noch das ganze als Funktion via Query!!

Geht das überhaupt

Grüße und Danke

Olaf

 

Verstehe ich dich richtig: du willst die Funktion "getDetailsemi" in einer Abfrage einsetzen.

Prinzip:
Code:

Das wäre somit 1200 Einsätze der getDetailsemi-Funktion.
Das sollte niemals 10 Minuten dauern, wenn ein Index verwendet wird.
Falls du auf eine verknüpfte Tabelle zugreifst, solltest du aber die wichtigste Maßnahme zur Geschwindigkeitsoptimierung beachten: ein dauerhaftes Recordset zum BE öffnen. Ich könnte mir vorstellen, dass das auch in diesem Fall etwas helfen kann.

Weiters könntest du noch statt CurrentDb nur eine einzige Refernez verwenden. (CurrentDbC usw.)

Das Beispiel von Michael Zimmermann hast du hoffentlich bereits angesehen und die Optimierungsmaßnahmen in deine Prozedur übernommen.


Bezüglich deiner Idee mit den 2 Recordsets: ich glaube nicht, dass du damit schneller Daten abfragen kannst als über eine optimierte SQL-Anweisung, die einen Index verwendet.

 

Ich lese das Ganze interessiert mit, verstehe aber noch nicht die Situation. In der Funktion getDetailsemi übergibst Du als 4. Parameter einen Tabellen-/Abfragenamen.

Um wieviele Tabellen/Abfragen geht es denn? Hat jede 20T Datensätze?

Ich würde nach Deiner Beschreibung deuten, dass Du die genannte Funktion 1.200x ausführst (mit wechselnden Parametern) und das daher das Tempoproblem herrührt.
Daher könnte es ein Ansatz sein, die Parameter deutlich weiter zu fassen und z.B. ein Recordset pro Tabelle/Abfrage mit allen relevanten Feldern zu öffnen und auszuwerten.

 

Hallo
ich frage mich nur noch ob Dir Bei 20t Ds nicht Dein String Feld Result
überläuft ? wird überigens nirgens geleert/ initialisiert

sonst hast Du von Josef und Eberhard schon alle guten Tip's erhalten

 

Im Anhang (#13) eine Test-Anwendung - allerdings mit lokaler Tabelle, dafür mit 200000 DS.
(Die Testdaten müssen zuvor mit der Prozedur "TestDatenAnfuegen" erstellt werden.)
In diesem Beispiel verwende ich das ConcatVar-Beispiel von Michael Zimmermann mit minimalen Änderungen.

 

Hallo Josef,
meine Indexe habe ich noch ein mal konrtoliert, alles wie es sein muß.
Ja die grundlegenden Daten kommen zwar aus einer vernüpften Tabelle die habe ich aber via insert fest als ExcelGesamt abgelegt und mit Alter tabel den Index angelegt.

Den Code vom zimmerman verstehe ich noch nicht ganz, wobei mir ein Fehler beim testen ständig an dieser stelle ausgegeben wird.
Code:

Aufruf erfolgt über ?ConcatVar("Cat","ExcelGesamt", "DLNR","8007272", ";",";")

Hast du eine Idee?


@ Hallo Rudolf
überlaufsperre fehlt noch aber das ergebniss ist im allgemeinen kleiner 255 zeichen,. Danke für den hinweis!

@ Hallo ebs
die daten kommen aus einer tabelle

Binn begeistert,
Danke für eure unterstützung

 

Hallo Josef,

Habe gerade deine test db ausprobiert is der hammer, jetzt kann ich deine aussagen verstehen ist die schnell.

erst mal danke , ich werde die Zimmermann lösung aufjedenfall bei mir umsetzen. der hammer...


Danke an Alle

 

Bei der von Michael geposteten Variante ist der String T etwas zu klein.
So ein Fehler im Code kann auch dafür sorgen, dass der Code nicht 1:1 übernommen wird. *biggrin.gif*

[OT]
Ich erwähnte einmal, dass Feld > '' besser als Feld IS NOT NULL ist. Ich diesem Beispiel bringt das überhaupt nichts. Jet merkte bei meinem Test nicht, dass ein Index vorhanden wäre, der alle erforderlichen Felder enthält. Gemäß Jet-Showplan entstand:
Code:

.. immerhin Rushmore. *Smilie
=> 2er-Index über fiT1 und T bring für diesen Abfragefall nichts.
Im Anhang daher noch eine Variante, die auf NOT NULL prüft und somit auch ein Zusammenfügen von Zahlenfeldern ohne besonderen Aufwand ermöglicht. .
Wenn statt einem Textfeld ein Zahlenfeld verwendet wird, dann klappt auch die Indexverwendung:
Code:

 

Hallo Josef,

ich habe mal die Datensatzerstellung um den Faktor 5 erhöht. Diese dauert etwas länger, die Abfrage selber (gefühlt etwa 1 sec.) nicht.
Atemberaubend. Stark.

 

Lösche einmal die Beziehung zw. den beiden Tabellen und führe dann die Abfrage noch einmal aus. ... dann siehst du was ein Index bewirken kann. *Smilie
(Anm.: den anfangs eingefügten 2-Felder-Index nahm ich aus der Tabelle wieder raus. Für ConcatVar wurde nur der Index von der Beziehung verwendet.)