Office: ADO Recordset aktualisieren

Hallo !

Ich habe ein Problem mit der Aktualisierung eines ADO Recordsets. Hier wird eine Änderung eines Datensatzes erst bei mehrfachem Schließen und erneutem Öffnen des Recordsets angezeigt. Mehrfach heißt zwischen einem und 4 mal in Abständen von jeweils einer Sekunde.

Die Änderung des Datensatzes erfolgt mit einer DoCmd.RunSQL Anweisung.

Hat jemand eine Idee an was das liegt ?

Unabhängig davon habe ich es übrigens nicht geschafft das Recordset mit Resync zu aktualisieren. Wie muss RS und Verbindung dafür geöffnet werden ?


Vielen Dank,

Steve.

... und der Code sieht so aus:

Deklarationen:

Code:

Öffnen der Verbindung (bleibt die ganze Zeit offen):

Code:

GetRegBackendPath liefert den BE Pfad.

Änderung durchführen:
Code:

lstPrintSettings ist eine Grid-Komponete.

Aktualisieren des Recordsets:

Code:

:)

 

Setze zusätzlich einen Verweis auf DAO und schreibe vor den Recordset-Aktualisierungen die Zeile:

DBEngine.Idle dbRefreshCache

Hintergrund: Das RunSQL schreibt Änderungen erst in den Cache, der von Zeit zu Zeit in die Tabelle physisch übertragen wird.
Dasselbe für's Lesen: Der Cache wird in regelmäßigen Abständen aktualisiert. (Siehe auch DBEngine.SetOption). Dadurch entsteht eine Verzögerung.
DBEngine.Idle dbRefreshCache erzwingt das Einlesen.

Vielleicht geht es auch besser, wenn statt
RunSQL >> DAO.Database.Execute sql verwendet wird. Vor allem, wenn in Transaktion eingebettet:

Dim dbs As Database 'Evtl.Public

DBEngine.BeginTrans
Set dbs=DBEngine.OpenDatabase(GetRegBackendPath)
dbs.Execute sql
DBEngine.CommitTrans dbForceOSFlush
' Optional: dbs.Close

dbForceOSFlush erzwingt das Speichern auf den Datenträger.

Alles in allem ein gutes Beispiel, dass man mit ADO einige Sachen nicht machen kann, die mit DAO gehen. (Wüsste jedenfalls nicht, wie das erzwungene Schreiben/Lesen mit ADO ginge).

Ciao, Sascha

 

Hallo !

Danke Dir für die Antwort.

Ich habe jetzt die Änderung mit dbForceOSFlush geschrieben, und vor der Aktualisierung DBEngine.Idle dbRefreshCache eingefügt.

... aber dann muß ich doch auch das Recordset über DAO öffnen, oder ?

Wenn ich bei ADO bleibe sehe ich keine Änderung im Vergleich.

Eigentlich sollte ADO verwenden werden, weil es in Mehrbenutzerumgebungen deutlich schneller ist.

Ich hab jetzt nochmal rumprobiert und wenn man die Verbindung schließt und neu öffnet ist ist der Cache leer.

Sollte ADO nicht eine Weiterentwicklung von DAO sein ? *rolleyes.gif*

Gruß,

Steve.

 

Hallo Steve.

ich verstehe nicht, wieso führst Du zuerst Docmd.RunSQL und dann öffnest Recordset. Statt ADODB.Connection kannst Du ADODB.Command dafür benutzen (oder Connection.Execute) oder (und) Recordset öffnen, im Recordset Filter setzen und mit eine Schleife änderungen führen und geänderte Recordset wieder einem Grid zuweisen ?

 

Sowohl DAO wie auch ADO benutzen als Datenbank-Engine Jet .
(Siehe ADODB.Connection.Properties(63 bis 95).
Deshalb gibt es IMHO keine nennenswerten Performance-Unterschiede zwischen beiden.

dbForceFlush müsste die Änderungen sofort in die Datei schreiben.
Ob ADO allerdings auf den gleichen Cache zugreift, wie DAO, dessen Daten mit dbRefreshCache aktualisiert wurden, kann ich nicht sagen. Möglich dass DAO und ADO in der gleichen DB unterschiedliche Engines mit jeweils eigenem Cache anlegen, so dass das dbRefreshCache unter ADO unwirksam bleibt.

Da es einen ähnlichen Befehl in ADO nicht gibt, weiß ich auch keine weitere Abhilfe.

Ciao, Sascha

 

Hallo.

ADO ist sogar langsamer als DAO aber viel umfangreicher.

Wenn Client die Änderungen nicht gleich bekommt, sollte man 2 Eigenschaften von Connection (2. auch für Recordset) ansehen:

Quelle: www.activevb.de

Ernst gesagt ganze Code bei Dir sind falsch. Gute (und kurze) Tutorals für ADO und ADOX findest du auf www.activevb.de

 

\@PBecker:

Wieso das?

Aus deinem Hilfeauszug geht eigentlich nichts hervor, was in Bezug zu Steves Problem steht...?

Er öffnet das Recordset ja neu. Da ist es egal, ob es per statischem Cursor geöffnet wird oder nicht.

Den Cache wiederum verwaltet Jet, nicht ADO, dem Überbau. Es ist auch für die Verzögerung verantwortlich.

Ciao, Sascha

 

Hallo Sascha.

“Mode=Share Deny None” - wozu ist Share? (sollte adModeShareDenyNone sein)
„DoCmd.RunSQL sql“- wenn die Tabelle lokal oder verknüpft sind, wieso dann zusätzliche Connection und ganze Geschichte mit ADO?
ADOrsPrintSettings.Open "SELECT qry_StandardPrinters.* FROM qry_StandardPrinters", ADOConnClient, adOpenStatic, adLockReadOnly
ADOrsPrintSettings.Requery
Zuerst adOpenStatic und adLockReadOnly und dann Requery.
verstehe ich absolut nicht. Ist nicht besser Cursor zu letzen DS und dann zu Ersten zu bewegen ? Mindestens steht Cursor dann richtig. Und ADO in der Fall benutzt auch Jet als Provider und Cursor Type ist auch sehr wichtig.
Bei Steve: Er sollte wahrscheinlich zuerst DoCmd.RunSQL führen, dann Connection öffnen u.s.w.
Oder Connection öffnen und mit Execute Daten ändern. In der Kombination, wie jetzt, ist nicht ganz sauber. Ich wollte damit Steve in keinem Fall beleidigen.

Schönes Wochenende.

 

@Paul

Du hast grundsätzlich vielleicht Recht, aber das Recordset, dass ich öffne kommt aus einer SQL-Abfrage, die per se nicht aktualisierbar ist. Die wird in einem Datengitter im Formular angezeigt (Druckereinstellungen für Berichte). Jetzt wird aus einer ComboBox ein anderer Drucker ausgewählt, und die Änderungen (ursprünglich) mit RunSQL gespeichert. Diese Änderung wirkt sich aber wieder auf die Liste aus, und diese muss aktualisiert werden.
In diesem Fall wäre es ggf. möglich die Sache so zu konstruieren, dass das Recordset aktualisierbar wäre, aber ich habe das gleiche Problem noch in einem anderen Formular, bei dem im Datengitter (mit "dem" Recordset as Datenquelle) eine Abfrage(Statistik) mit Gruppierungen, Outer Joins und Unions angezeigt wird. Allzu dreckig ist mein Code glaube ich nicht. *wink.gif* Es sollte halt ein Minimalbeispiel für ein grundsätzlichen Problem sein.

Die Einstellungen mit dem Cursor habe ich durchgetestet, und ich habs auch mit adOpenKeyset versucht. Die Sache, dass das statische Öffnen
keine Aktualisierung erlaubt ist im Prinzip egal, weil das Recordset nach Änderungen komplett neu geöffnet wird.

Saschas Einschätzung mit dem Cache klingen plausibel, oder ?

------

@Paul, Sascha

Ich habe den Performance Unterschied mit DAO /ADO nochmal getestet. Und zwar wirkt es sich (bei mir zumindest) besonders in langsamen, stark ausgelasteten Netzen aus.

Hier der Testcode aus einem Formular, das Wesentliche kann man (hoffentlich) erkennen:

Code:

 

Hallo Steve.

Alles, was ich erklären wollte, dass ich einfach eine Connection und dann mit SELECT WHERE Recordset öffnen, Daten ändern, Recordset.Update machen, Recordset nicht schließen, einem Grid zuweisen würde. Dann soll ich nicht unbedingt warten, bis Daten in der Tabelle vollständig aktualisiert sind. Ich habe doch schon auf meinem Computer einen Recordset mit aktuellen Daten.
Es tut mir leid, dass ich das nicht richtig erklärt. Es liegt, wahrscheinlich, an meinen keine perfekten Deutschkenntnissen. *eek.gif*

Und, dass DAO schneller als ADO ist, habe ich nur in einigen Bücher und auf manchen Webseiten (von DAO-Fans ? *rolleyes.gif* ) gelesen. Selber nicht geprüft, weil ich nicht vorhabe, mit ADO und DAO gleichzeitig zu arbeiten. Ich habe mich für ADO entschieden.

 

Mal ein Nachtrag zu Steves Performance-Tests (...bei denen ich nicht so ganz durchgestiegen bin *wink.gif* )


Test DAO ADO

System: W2k SP3; A2000 SP3; MDAC2.7; Jet7 SP4 (beta); P900

Datenbank: MDB mit 63Mb; Tabelle mit 58000 Datensätzen;
1000 Datensätze zufallsgesteuert über Recordsets aus Abfrage lesen und/oder schreiben;
(DAO: Über verknüpfte Tabelle; ADO: Connection zum Backend; adUseServer!)


Zeiten lokal:

DAO read snapshot: 8682 ms
ADO read static: 3074 ms

DAO read dynaset: 1953 ms
ADO read keyset: 2073 ms
ADO read dynamic: 921 ms

DAO edit dynaset: 4627 ms
ADO edit static: 5078 ms
ADO edit keyset: 4567 ms

Dasselbe mit Zugriff über 10Mbit-Netz:

DAO read snapshot: 153 s
ADO read static: 155 s

DAO read dynaset: 145 s
ADO read keyset: 140 s
ADO read dynamic: 134 s

DAO edit dynaset: 267 s
ADO edit static: 167 s
ADO edit keyset: 160 s


Die Unterschiede sind also nicht erheblich, auch wenn ADO bei schwachem Netz geringfügig schneller ist (vor allem bei Recordset.Edit ). DAO-Snapshots sind auch ziemlich langsam, aber das ist auch bekannt (weil alle DS eingelesen werden).

@ Steve:

Vielleicht setzt du mal

ADOConnClient.CursorLocation = adUseServer

Das ist eigentlich der Standardmodus. Möglicherweise hast du dein Problem dann nicht mehr.

Ciao, Sascha

 

Mit dem Serverseitigen Cursor habe ich die Parameterabfrage nicht hinbekommen, deshalb der Clientseitige. Ausserdem steht bei Doberenz, Kowalski (Access 2000 Programmierung):

Für einen Zugriff auf .mdb Datenbanken (Jet Engine) ist sowohl ein clientseitiger als auch serverseitiger Cursor möglich. Letzterer ist etwas schneller, funktioniert aber nach der Erfahrung der Autoren nicht immer einwandfrei , wenn mehrere Datensätze gleichzeitig angezeigt werden sollen (z.B. in einem DataGrid oder einer DataCombo). (nicht selbst getestet)


Nochmal ein Wort zu meinen kleinen Test. Ich habe als "Testumgebung" zwei WinXP home PCs über Crossover verbunden. Und wirklich eingesetzt wird die DB in einem 5 PC (Win2000 pro) Netzwerk mit einem Win2000 Server und 100 MBit vernetzt.

Die Performance in der Produktiv-Umgebung läßt sich rel. gut simulieren, wenn man die Geschwindigkeit der beiden Netzwerkkarten der WinXP PCs auf 10 MBit stellt und dann von einem PC aus eine große Datei auf den anderen kopiert (das meinte ich mit höherer Auslastung). Meine eff. für Access zur Verfügung stehende Breite liegt wahrscheinlich noch ne Ecke unter den 10 MBit/s. Vielleicht kommts ja dadurch.

Er hat übrigens so funktionert, dass ein Wert der ausgewählten Zeile einer Liste als Parameter für die Testabfrage genommen wird. Und obiger Code stand im onClick Event der Liste. Da kann ich mit Deinem Zufallsprinzip also nicht wirklich mithalten....

Naja, dann werde ich wohl noch etwas testen müssen....

Danke Dir *top ,

Steve.

(Access 2000 SP3, MDAC 2.7 SP1 und Jet 4 mit SP 6)