Access, ADO, Datenverlust,
-
Tja... so was Blödes... ein anderer Kollege hat eine Lösung gefunden: ein Requery zwischen dem Schreiben zweier Tabellen der gleichen DB, die irgendwie in Zusammenhang stehen. Ich liebe es, in die falsche Richtung zu rennen...
-
HEZ schrieb:
... ein anderer Kollege hat eine Lösung gefunden: ein Requery zwischen dem Schreiben zweier Tabellen der gleichen DB, die irgendwie in Zusammenhang stehen. ...
Versteh ich nicht (liegt vielleicht daran, dass ich letzte Nacht zu wenig Schlaf hatte).
Das Requery ist die Lösung? Sprich Datenquelle schließen und neu öffnen löst das Problem?
-
Ich versteh auch nicht, warum das jetzt funktioniert. Es ist halt einfach so.
Zwei Tabellen sind miteinenander verbunden, die eine Tabelle (B) zeigt die zugehörigen Daten zu einem Bestimmten Datensatz der anderen Tabelle(A) an (Links jedes Datensatzes wird ein "Expand-Button" angezeigt, der dann die Tabelle in der Tabelle öffnet). Beim Beschreiben muss man nun erst A beschreiben, dann A requeryen (
) und dann B beschreiben. Und dann passt alles. Vielleicht war er nicht in der Lage, den erforderlichen Datensatz in A zu finden, konnte deshalb die Verbindung nicht herstellen ... und hat deshalb nur 3 von 4 zugehörigen Datensätze in B geschrieben. Blödsinn.Tja, nicht die geringste Ahnung.
-
Das kommt nun drauf an, wie die Daten geschrieben werden. Wenn die Daten über Edit() oder Insert(), mit Post() eingefügt werden, sollte das ohne Requery funktionieren. Wenn die Daten per Update- oder Insert-Statement in einer eigenen z.B. ADOCommand ausgeführt werden, ist dieses Verhaltne normal. Man 'sieht' in einer Datenmenge immer nur die beim Zeitpunkt des Öffnens vorhandenen Datensätze, danach durchgeführte Änderungen werden erst bei einem Requery verfügbar.
-
Es ist mit Append und Post...
-
Ok, dann schließe ich mich deinem Unverständnis an.
Wenn Du noch was rausfindest, poste es bitte. Das interessiert mich.
-
auf die gefahr hin, dass ich völlig falsch liege... ich hatte ein ähnliches problem, als ich daten in access über odbc geschrieben habe.
letztlich lags daran, dass in meine quellcode der schreibvorgang schon beendet, also der nächste befehl aufgerufen wurde. die daten waren in der datenbank noch nicht geschrieben.
gelöst hab ich das sehr unelegant, dass ich nach jedem schreibbefehl ein paar sekunden gewartet habe, aufgerufen als funktion.
danach hat alles prima funktioniert, und alle daten sind immer angekommen
-
daniel12345 schrieb:
letztlich lags daran, dass in meine quellcode der schreibvorgang schon beendet, also der nächste befehl aufgerufen wurde. die daten waren in der datenbank noch nicht geschrieben.
Ich habe keine Ahnung, was das heißen soll...
-
Bei Access mit ADO fiel mir in der Vergangenheit zusätzlich auch noch negativ auf, daß ein Update der Jet-Engine (sprich: neuer MDAC installiert) zu anderem Verhalten beim Zugriff führte. Nicht unbedingt in die bessere Richtung, ein paar Dinge gingen danach auch einfach nicht mehr. Da kann man sich also auch noch eine Menge Ungemach einfangen.
-
Dann werde ich mal einen Updateverzicht empfehlen.
-
nun, ich hab halt über ein recordset eine datenbank gefüllt. im speziellen fall hab ich eine kreuztabelle, bspw 200 x 200 erzeugt. die datensätze habe ich über ne while -schleife eingetragen, update, requery und wollte dann wieder auf die tabelle zugreifen.
beim nächsten zugriff aus der mfc-anwendung waren aber noch nicht alle daten eingetragen, meistens fehlten so die letzten 3 bis 4 spalten. wenn ich mit dem nächsten zugriff ein oder 2 sekunden gewartet habe, waren die daten alle da.