Re: Zurückschreiben der DB auf die HD

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Hallo Susann,

vielen Dank für Deine Antwort. Klingt sehr logisch und deckt sich ja
*fast* mit meiner Vermutung, dass die Daten noch im Arbeitsspeicher
liegen, wenn es auch hier eben der Cache ist.

Ich habe Deine Code-Ergänzung 1:1 umgesetzt, aber leider auch hier
Fehlanzeige.
Dann hast Du das "JetEngine.RefreshCache" sheinbar nicht für deine
verwendete Connection ausgeführt.
Ich verwende das beschrieben "Cache refreshen" schon seit vielen Jahren
in sehr Zeit kritischen Mehrbenutzer Systemen, wo an anderen Arbeitsplätzen,
in Bruchteilen von Sekunden, die aktuallisierten Daten benötigt werden.
Allerdings geht es da mehr darum, dass nicht jemand den PC ausschaltet,
sondern darum das die neuen Daten sofort an allen anderen Arbeitsplätzen
zur Verfügung stehen. Aus diesem Grund refreshe ich den Cache,
in den zeitkritischen Aktuallisierungen, nicht nur nach einem RS.Update
sondern auch direkt vor dem RS.Open.
Das klappt bis dto. hervorragend.
Die Connection wird beim Programmstart geöffnet und erst beim Beenden
wieder geschlossen.

Frage: Gibt es eine Möglichkeit abzufragen, ob das Leeren des Caches
erfolgreich war und die Daten physisch zurückgeschrieben wurden?
Ist mir nicht bekannt. Das Refreshen sollte aber normalerweise nur
Millisekunden dauern.
Wenn der Datensatz (Datensatz - weil .Update) wirklich nicht in Bruchteilen
einer Sekunde in die DB geschrieben wird, dann versuch es damit:
1. Das doppelte "Set rcsDest = New ADODB.Recordset" entfernen.
2. Nach "Je.RefreshCache conDest" das RS noch mal öffnen und
gleich wieder schließen. ???


Meine Code-Einfügung "Set Je = New JRO.JetEngine" sollte zur besseren
Lesbarkeit und von der Ablauflogik her über
"File = App.Path & "db\messdaten.mdb" eingefügt werden.
Also:
...
Set Je = New JRO.JetEngine
File = App.Path & "db\messdaten.mdb"
Set conDest = New ADODB.Connection
conDest.Open ...

Set rcsDest = New ADODB.Recordset
rcsDest.Open ...
...


Gruß
Wilfried


.