Office: (Office 2010) Performance verbessern

Danke
Jürgen

zu dem was Du Sagst und den was ich gesagt habe kämme heute noch die Frage
der Umwelt Belastung dazu *wink.gif*

 

Wie das gemeint ist, weiß ich nicht, aber eine Gegenüberstellung alter LKW gegen Porsche gibt mir ein Bild von etwas Geräumigen, aber Langsamen einerseits und einem sehr schnellen engen Raum andererseits, und das ist im obigen Zusammenhang Abfrage versus Domänenaggregatfunktion nicht stimmig.

Bekanntlich wird eine Domänenaggregarfunktion öfters, u.a. wegen Performance, durch eine Ersatzfunktion mit Abfrage und Recordset ersetzt. Das hieße auf das Bild bezogen, der LKW ist mindestens genau so schnell wie der Porsche, und mehr Aufwand (Sprit) braucht er auch nicht.
Da wir in der IT dann auch kein reales Parklücken- und Garagenproblem haben, fällt dann die Wahl ziemlich leicht.

 

Natürlich sind die beiden Angaben nur zum Testen vorgegeben worden. Später wird ein Testprogramm (TpNr) gewählt und die Testschritte (StepNr) in einer For-Next Schleife durchlaufen

Bin gerade dabei alles umzustricken. Bin schon gespannt wie viele Sekunden ich für einen Testablauf einsparen werde.

 

Dann sollte man die Parameter für die Tests wie oben angesprochen in eine Tabelle bringen und diese Tabelle mit der Datentabelle in einer Abfrage verknüpfen. Damit sind dann das Recordset und die Do-While-Schleife etwas gehaltvoller.

 

Wie willst du dann das Recordset verwenden?
Je ein Recordset pro StepNr oder ein Recordset pro TpNr und das Recordset mir For-Next o. ä. durchlaufen?

mfg
Josef

 

Bisher sieht mein neuer Ansatz wie folgt aus:
Code:

Alleine damit erspare ich mir seeeeehr viele Zeilen und ich bin mir sicher man könnte weiter optimieren.

 

Wünsch euch schon mal schöne Feiertage ... werde nach meinem Urlaub hier wieder angreifen!

 

Das ist so sicher, wie das Amen in der Kirche. Da ist einiges sehr sehr gruselig :-)
Aber ohne nähere Hintergründe (Beispiel-DB) Sinn, Zweck und Ziel der Übung sehr schwer zu beurteilen

Besides:

wobei das Kleinigkeiten sind... im Gegensatz zu dem was der Code an Ungereimtheiten erahnen lässt.

 

Hallo
Hier :
Code:

machst du 3x die gleiche abfrage !
Wie so nicht 1x abfragen und die die 3 Zuweisungen ?

und wie so if No x > 0 Then
....
für mich besser
Code:

 

Hallo zusammen,
ich wünsch euch erstmal ein schönes neues Jahr!

@ Rudolf:
da hast du vollkommen recht, drei mal die gleiche Abfrage durchzuführen macht natürlich keinen Sinn. Hab dies gleich geändert. Ich finde manchmal ist ein "if not" einfacher zu verstehen im Code. immerhin weiß man dann sofort auf einen Blick was ausgeschlossen werden soll.

@ fredfred:
ohne das db.close läuft der code bei mir nicht. bekomme dann folgende Meldung: "Object variable or With block variable not set"

 

Ich möchte jetzt meinen aktuellen Code nochmal posten und gewisse Passagen verdeutlichen:

Bei diesem Code-Modul wird ein Messgerät mit mehreren Messkanälen angesteuert. Messungen, Trigger, Kanäle usw müssen übergeben und die Messung somit parametriert werden.

Jeder Testschritt kann bis zu 8 Messungen beinhalten. Die Anzahl an Testschritten ist dabei unbegrenzt.

Trigger einstellen:
Code:

Messung und Messkanäle einstellen:
Code:

Messparameter einstellen:
Code:

Messung im Gerät ausführen (Ergebnisse werden im Speicher des Gerätes zwischengespeichert)
Code:

Messergebnisse aller Kanäle eines Testschrittes einlesen, umrechnen und darstellen:
Code:

 

Was ist hier der Anlass? Immer noch die Performancefrage?
Code:

Wenn eingangs gleich solche unbekannten Prozeduren auftauchen, schaltet zumindest bei mir das Verständnis sofort ab.

Falls es immer noch um Performance in einer Datenbank geht, würde man vorzugsweise NICHT alle Schritte einzeln und nacheinander unternehmen (Analogie zu DLookup oben), sondern versuchen, alle Berechnungen auf einmal zu unternehmen. SQL mit seinen Methoden zur Massendatenverarbeitung wäre da ein gutes Mittel, siehe Grundlagen - SQL ist leicht (0) - Vorspiel

Für ergebnisbringende SQL-Anweisungen bräuchte man durchdachte Tabellen (Datenmodell) und eine Darstellung des Zieles. Dies alles aus einigen Schleifencodes abzuleiten ist eine Zumutung bis eine Unmöglichkeit und daher den Versuch nicht wert.
Also zeige im Bedarfsfall, was Du hast an durchdachten Tabellen (Datenmodell) und Darstellung des Zieles.

 

Da hast du natürlich vollkommen recht....

Code:

mit diesem Aufruf wird die Schnittstelle des Messgerätes geöffnet (In diesem Fall ist es eine USB Schnittstelle). Die Adressen aller Geräte sind in der Tabelle Komponenten hinterlegt.

Ja es geht immer noch um die Performance ... obwohl ich alleine mit diesem Umstellungen bereits sehr viele Sekunden einsparen konnte.

Alle Berechnungen im Voraus? Das kann ich mir jetzt nicht wirklich vorstellen. Vorallem weil ja das Gerät in jedem Prüfschritt einen anderen Messwert ermittelt. Die Ergebnisse (strRes_DataAcquisition) sind mir ja im Voraus gar nicht bekannt. Bekannt ist nur was gemessen werden soll und welche Toleranzen eine jede Messung hat.

 

Gut, dass ein Messgerät jeweils nur eine Messung mit jeweils definierten Parametern ausführen kann, ist leicht nachvollziehbar und dann nicht änderbar.

Aber auch: Massendatenverarbeitung schlägt meist serielle Einzeldatenverarbeitung. Da könnte man prüfen, was damit bei Bereitstellung der Parameter sowie dann bei Abnahme und Auswertung der Ergebnisse möglich ist. Mit diesem Willen müsste man sich dann mit der Schnittstelle beschäftigen, was diese zulässt.

 

Hallo
@u.gross
evtl. hilft so was noch etwas
Eine andere Metode für CurrentDb (CurrentDBC):
Man definiert in einer Allgemeinen Modul folgendes:
Jetzt verwendet man im ganzen Code immer
CurrentDBC Anstelle von CurrentDB z.B.
Set rs3 = CurrentDBC.openRecordset("TblT", dbOpenDynaset)

Code:

möglich das Du auch in meiner Doc. s. Fusszeile unten rechts
ab Seite 54
5.2 Performance Verbesserung
noch was findest