Office: (Office 2003) DAO-Recordset einem Formular zuweisen

Hallo Eberhard,

Sagt mir erst einmal gar nichts. Habe bisher um ADO einen weiten Bogen gemacht und nähere mich nun (wg. MySQL-BE) so laaaangsam an.

MD5-Hash ist mir schon mal beim Querlesen untergekommen, sagt mir aber auch nicht mehr.
Ist das ein Wert, den man in einer "normalen" Variablen (keine Objektvariable) speichern könnte?

Speicherüberlauf findet keiner statt. Die Größe der DB wächst wie Einzeller in der Petrischale unter Optimalbedingungen. *wink.gif*

wegen der Parameterabfrage als Datenherkunft, die sich aus mehreren Unterabfragen zusammensetzt (siehe DB-Anhang in #15). Ich wüsste jedenfalls nicht, wie man ein Form an eine Parameterabfrage bindet und automatisiert die Parameter befüllt.

 

Ich kann bei der Beispiel-mdb keine außergewöhnliche Vergrößerung feststellen.
Nur die übliche Vergrößerung nach dem Komprimieren und dem ersten Start des Codes. Danach bleibt bei mir die Größe stabil, solange ich den Code nicht ändere. (Getestet mit Ac2010)

mfg
Josef

 

Hallo Marsu,

wegen der Parameterabfrage als Datenherkunft, die sich aus mehreren Unterabfragen zusammensetzt (siehe DB-Anhang in #15). Ich wüsste jedenfalls nicht, wie man ein Form an eine Parameterabfrage bindet und automatisiert die Parameter befüllt.

das funktioniert aber. Ich habe es gerade mit Deiner Beispieldatenbank ausprobiert.

Du sorgst dafür, dass das Recordset als Datenquelle zugewiesen wird. Dann lässt Du, gesteuert über einen Timer, die Datenquelle regelmäßig aktualisieren. Einfach mit Requery.

CU

 

Wie ermittelst Du automatisiert die benötigten Parameter? Wenn Du sie dem zu erzeugenden Recordset zuweisen kannst, kannst Du sie auch einer SQL-Anweisung zuweisen (den Aufwand halte ich für niedriger):
Code:

Die Abfrage muss in jedem Fall ausgeführt werden, auch bei der Recordset-Erzeugung. Also könnte man sie direkt dem Formular zuweisen, auch ohne Änderung der Daten und Prüfung auf Änderung.

Um meinen ersten Gedanken von oben etwas ausführlicher darzulegen:
Hashes haben den Vorteil, das sie sich bei der kleinsten Änderung der Quelldaten komplett ändern, auch bei Groß- und Kleinbuchstaben. Es ist sichergestellt, dass zwei Hashes nur dann gleich sind, wenn die Ausgangsdaten exakt gleich sind. Trotzdem sind sie viel kürzer, z.B. bei MD5 nur 128Bit, entsprechend 32Hex Zeichen. Das lässt sich in einer Variablen speichern.
Code:

Der Hash wird aus einem String gebildet. Somit könnte eine aus der Abfrage erzeugte SQL-Liste die Basis dafür sein. Wege, diese SQL-Liste zu erzeugen, gibt es mehrere, die Methode GetString auf ein ADODB-Recordset wäre einer davon. Da eine Abfrage viele Daten enthalten könnte, wäre vor allem Wert auf eine laufzeitoptimierte Variante zu legen.

Aber, wie bereits nachgefragt und inzwischen geprüft: Direktes Aktualisieren ist überzeugender.

 

\@ Josef

Das ist ja sehr interessant. *boah Bei mir Acc2003Pro(Sp2) wächst die DB bei jedem Klick auf Füllen also je 100 Durchläufe um ca. 2 MB.
Aufgrund deines Tests gerade mal mit der Acc2007-Runtime getestet mit dem Ergebnis, dass keine Vergrößerung stattfindet *confused.gif* *confused.gif* *confused.gif*

@ Thomas
Danke für´s Ausprobieren. Ich hatte gar nicht dran gedacht einfach ein Requery durchzuführen. Der Grund ist, dass sich die Parameter öfter mal ändern können und das RS dem Form neu zugewiesen werden muss. Womit - jedenfalls unter 2003 - das Problem bestehen bleibt.

@ Eberhard

Bei einer einfachen Abfrage wär das kein Thema und ich würde dir vorbehaltlos zustimmen. Bei dem Abfragenkonstrukt aus mehreren Parameterunterabfragen ist es zwar auch möglich, doch sehr komplex und ich würde den Performancevorteil von gespeicherten Abfragen verlieren.

Danke dir für den Hash-Ansatz. Das werde ich mir mal Näher ansehen.

 

Mich würde ja nebenbei interessieren, wie Du Recordsets miteinander vergleichst?
(Acc2003-DB´s sehe ich mir erst auf meinem neuen Rechner an.)

Nicht, dass etwa Performancevorteile durch gespeicherte und kompilierte Abfragen durch - ich sag mal - umfangreiche Aktionen rundherum aufgehoben oder gar ins Gegenteil verkehrt werden.

 

Darüber hab ich mir bisher wenig Gedanken gemacht. Das ein Vergleich ala RS1=RS2 nicht funktioniert, ist mir bewusst. Wahrscheinlich würde ich den RS-Vergleich über Arrays lösen. Bin aber gerne für andere Ideen offen.

Ich würde mich schwer tun die 8 Einzelabfragen aus der Beispiel-DB in einen einzigen SQL-String zusammenzufassen. Wenn jemand Zeit und Lust hat und darin eine Herausforderung sieht ... bitte gerne *wink.gif*

Die Performance werde ich letztendlich im Gesamtzusammenhang testen. Momentan habe ich eine stabile und schnelle Lösung (s.o.). Nur schadet es ja nie, für noch mehr Performance zu sorgen.

 

Hast du eigentlich schon einmal ADODB statt DAO ausprobiert?

Z. B.:
Code:

Verwendung:
Code:

 

Das wäre zeitlich sehr wahrscheinlich eine größere Nummer als eine nichtkompilierte Abfrage, abgemildert dadurch, wenn man einen Feldunterschied gleich am Anfang findet.

Dann doch besser die neue Datenherkunft direkt zuweisen ohne Prüfung, auch wenn es evtl. die gleiche ist. So lautet ja auch sinngemäß Josef´s Vorschlag: Altes Formularrecordset schließen und zerstören und dann umgehend das neue zuweisen. Prüfen ist überflüssig.

 

\@Josef
Danke für die ADO-Lösung. Leider liefert das RS nicht die richtigen Datensätze, so als ob die Parameter nicht überall ankommen (Index 1-39 ist ok; keine Patientennamen). Hab ein bisschen herumprobiert. Als ADO-Laie, weiß ich nicht an welcher Schraube ich drehen sollte. Jedenfalls scheint ADO wachstumshemmend zu sein *wink.gif* Es ergab sich bisher keine spürbare Vergrößerung der DB. Wäre nett, wenn du oder jemand anderes sich das noch mal anschauen könnte.

@ Eberhard

... hilft beim Vergleich auch nicht weiter. Da sich der SQL-String nur ändert, wenn sich die Parameter verändern. Für einen Vergleich aktuelle Datenbestand vs. Neuer Datenbestand brauche ich ein bzw. zwei Recordsets.

Wie bereits thematisiert wächst die DB unter A2003 bei dieser Vorgehensweise stark an!

Hatte ich in meiner Beispiel-DB bereits so gelöst. Wenn du magst, stell ich dir gerne eine 2000er Version zur Verfügung *wink.gif*

 

Bezüglich ADODB.Command: In der Abfrage "qry_TP" fehlte bei dir die Parameter-Definition. ADODB ist anscheinend nicht so tolerant als DAO. *wink.gif*

mfg
Josef

 

Danke dir Josef, da DAO so "verständnisvoll" ist, denke ich da selten dran.
Jetzt läuft´s ohne Aufblähen. Weiß der Henker, welchen Unterschied Access da zwischen dem ADO und DAO Recordset bzgl. Speicher macht. Da du rst ja nicht mal schließt wäre ich davon ausgegangen, dass das auch negative Folgen hat.

Naja, muss mich im Zuge der zukünftigen geplanten Umstellung der Anwendung auf ein aktives DBMS eh mehr mit ADO beschäftigen. Finde nur die Syntax im Vergleich zu DAO umständlicher.


[Edit]
Interesseren würde mich schon, warum die DAO-Variante unter A2003 zum Aufblähen der DB führt und dieser Effekt in den späteren Versionen nicht mehr auftritt.

Bleibt noch die Frage, wie man zwei RS performant miteinander vergleicht (Inhalte). Aber das wird dann zu gegebener Zeit ein neues Thema *Smilie
[/Edit]

 

Vorschlag:
Code:

Code:

 

Zum Vergleichen könnte die ADODB-Variante praktisch werden:
Code:

Wenn die Recordsets allerdings einige tausend DS beinhalten, wird das nicht besonders flott sein.
Daher die Frage (Eberhard schrieb das bereits): Warum überhaupt vergleichen?

mfg
Josef

 

Das ist der Versuch (so habe ich es verstanden), das oben beschriebene Aufblähen zu verlangsamen: Nur bei Änderung soll das Formularrecordset getauscht werden, daher würde der Aufwand der Änderungsprüfung (= Performanceverlust) in Kauf genommen. Eine richtige Lösung ist dieser Weg allerdings nicht.