Office: (Office 365) Kombination von zwei Abfragen in PQ mit Abhängigkeiten

Guten Morgen Luschi,

Zuerst einmal vielen Dank für die Infos sowie das Referenzmaterial. Aus der Mappe GDE's_LPOSO_GDE003.xlsx geht leider nicht hervor, wie Geert die Laufzeit gemessen hat. Auch wären alle Laufzeiten inakzeptabel, wenn diese aus der Verarbeitung der 1.000 Datensätze der Tabelle fSales resultieren. Erkennbar ist somit nur, dass bei der Konstellation: "Viele Verkaufsdaten, wenige Rabattsätze" die Variante mit "Table.Combine", eindeutig die langsamste ist.

Hier, bei der aktuellen Fragestellung haben wir aber fast ein 1:1 Verhältnis der Datensätze von Produktionsbeginn und Produktionsende. Dazu kommt, dass wir hier ja mehrere Arbeitsplätze haben, zu denen die jeweiligen Produktionsendzeiten ermittelt werden müssten.

Somit wüsste ich jetzt nicht, wie ich jetzt z.B: Lösung mit "List.PositionOf) adaptieren könnte.

Um aber mal testen zu können wie lange meine Variante mit "Table.Combine" läuft, habe ich für die 2 Ausgangstabellen eine beliebig einstellbaren Multiplikator eingebaut und es dann mit 100.000 Datensätzen getestet. Für die Laufzeitmessung habe ich dann den im cef veröffentlichten Remote Refresh verwendet. Nach 12 Durchgängen habe ich auf meinem 8J alten I7 /ein min. von 4,653 Sek., ein max. von 5,437 Sek. und ein avg. von 4,494 Sek. Somit zumindest mal eine Laufzeit, mit der man leben kann.

Bei der Multiplikator-Mappe, die ich jetzt auch einmal hochlade, müssen zuerst die Abfragen ZP_1 und ZP_2 aktualisiert werden, bevor dann die Abfrage "ZP_1_ergänzt" für eine Laufzeitmessung (Remote, oder per Hand und Stoppuhr) gestartet werden kann, da ich ja die Datenmenge für den Upload reduzieren musste.

Ich hätte zwar das Ergebnis der Datenmultiplikation (Vervielfachung) auch als "Verbindung" laden können, aber dann würde diese ja bei jeder Aktualisierung von "ZP_1_ergänzt", automatisch durch PQ aufgerufen werden. Dass lässt sich ja nur verhindern, wenn von Datenquellen gelesen wird, zu denen Power Query keinen Vorgänger feststellen kann.

 

Vielen Dank euch allen und Danke auch für die Diskussion. Hier konnte ich wieder einiges dazu lernen. Für mich funktioniert die Lösung von ws-53 sehr gut. Bezüglich der längeren Dauer bestimmter Zeiten, ist dies auf Unterbrechungen oder Wartungen im Produktionsprozess zurückzuführen.

 

Ich habe nun die Mappe GDEs_LPOSO_GDE003.xlsx auch um die Vervielfältigungsabfrage (100.000 Datensäzte) erweitert und die 5 Abfragen remote aktualisiert. Die Laufzeiten gehen hierbei von 3,1 bis 5 Sek. liegen. Wobei ich hierbei vorher auch den Parameter "ClipSize" hochgesetzt hatte, da ich den Eindruck hatte, dass Power Query diese Beschränkung intern vorzieht und somit die tatsächliche Laufzeit verfälscht wird.

Dabei habe ich auch festgestellt, dass das Abfragepräfix für jede neue Abfrage durch die jeweils aktuelle Sprache gesetzt wird.

Anbei auch die Mappe GDEs_LPOSO_GDE003_Multiplikator.xlsx, mit der sich über den Remote Refresh sehr bequem die Laufzeiten für die unterschiedlichen Methoden ermitteln lassen. Wobei dann auch zuerst die Abfrage fSales_Mult aktualisiert werden muss, damit die Tabelle auch wieder vollständig ist.

 

Hier geht's zu dem Beitrag: Power Queries ferngesteuert aktualisieren
Power Queries ferngesteuert aktualisieren

Bei dem es nun keine Rolle mehr spielt, mit welchem Präfix die Abfragen einer Mappe versehen sind.

 

Hallo Luschi,

hast du mal auf deinem PC die Laufzeiten der verschiedenen Methoden der Mappe GDEs_LPOSO_GDE003_Multiplikator.xlsx ermittelt?

 

Hallo ws-53,

ja. ich habe getestet :

- Du hast zwar die Abfrage 'fSales_Mult' erstellt
- aber alle Abfragen der Gruppe 'fSales_Mult' verweisen auf 'fSales'
also nur auf 31 Datenzeilen
- das habe ich natürlich geändert
- aber diese Vba-Zeilen in der RemoteRefresh-Makrodatei können nicht korrekt sein:
.ListColumns("Start").DataBodyRange(idx).Value = PQ_start / 86400
.ListColumns("End").DataBodyRange(idx).Value = PQ_end / 86400
- warum teilst Du durch 60 * 60 * 24 (also 1 Tag in Sekunden)?
- bin z.Z. daran beschäftigt, die Vba-Schleife For Each conn In wb.Connections
- so zu verändern, daß das 'Exit For' nicht mehr erforderlich ist
- aber auch die vorgeschlagene PQ-Aktualisierungs-Reihenfolge eingehalten wird
- außerdem verfolge ich gerade das PQ-eBook:
96 Common Challenges in Power Query
vom Verlag Apress-2025
- da geht es in PQ-M ganz schön zur Sache (Interesse?!?)

Gruß von Luschi
aus klein-Paris

 

Hi Luschi,
das ist korrekt, da ich mir ja Start und Ende durch die Funktion "Timer" ermitteln lasse und nur so auf die Uhrzeit komme.

Es kann aber durchaus sein, dass es da elegantere Möglichkeiten gibt.

Wie liest du das PQ-eBook? Am PC, oder hast du einen eBook-Reader? Beim letzten eBook, da ist das kopieren von Textausschnitten wohl irgendwie technisch gesperrt. Sodass es mir nicht vergönnt war, Textausschnitte, die ich mir sicherheitshalber mal durch Deeepl.com übersetzten lassen wollte, dies auch zu tun.

 

Hallo ws-53,

habe gerade noch mal getestet:
PQ_start = DateTime.Now mit dem Ergebnis 45865,3276157407 bzw. 27.07.2025 07:51:46
PQ_start = PQ_start / 86400 mit dem Ergebnis 0,530848699256259 bzw. 00.01.1900 12:44:25

Deshalb verstehe ich diese Division mit 86400 nicht.

Gruß von Luschi
aus klein-Paris

 

Moin!
Als PQ-DAU sei mir der Hinweis auf VBA gestattet:
Timer ergibt die Anzahl der Sekunden (auf 1/100 genau) seit Mitternacht.
Now ergibt einen Date-Time-Stamp (auf die Sekunde genau).
Letzteres eignet sich daher eher nicht, um Laufzeiten zu ermitteln.
Aber auch ich sehe keine Notwendigkeit, durch 86400 zu teilen.
Dies brauche ich doch nur, um aus einer Dezimalzahl die Dauer in Sekunden zu ermitteln.
Mal ein bewusst beklopptes Beispiel (Appplication.Wait ist ungenau, siehe Hilfe …):

Code:

Sub Dingens()
Dim Start#
Start = Timer
Application.Wait Now + TimeSerial(0, 0, 10.345)
Debug.Print "richtig ist: " & Timer - Start
Debug.Print "zu ungenau ist: " & Format((Timer - Start) / 86400, "s.000")
End Sub

ergibt im Direktfenster:

Code:

richtig ist: 9,68359375
zu ungenau ist: 10.000

Gruß Ralf

 

Guten Morgen Luschi,

vor Jahren, als ich mal eine Laufzeitmessung mit Bruchteilen von Sekunden brauchte, hatte ich es nicht anders hinbekommen und deshalb bisher so beibehalten.

 

Wenn ich einen soeben ermittelten Timerwert von 52790,6015625 durch 86400 dividiere, ergibt sich daraus due Uhrzeit: 14:39:50 ,602. Das ist für die Laufzeitmessung natürlich nicht notwendig. Aber wenn ich die Uhrzeit des Timerwerts wissen möchte, dann würde mir ein, zusätzliches, NOW einen anderen Wert liefern.