Access, ADO, Datenverlust,
-
Ui, da hat sich ja jemand dazwischengequetscht.
Nun, die Ente ... he, ich hab gesagt, ihr sollt nicht fragen!
Meinst du mit "was man in Access sieht" nun die Oberfläche von Access selbst oder die Daten, die man bekommt? Schließlich ist ja beides gekürzt...
-
Handelt es sich möglicherweise um ein Quietscheentchen-Tattoo ?
Ich habe hier eigentlich nur ein Programm, das schreibt und liest, also nacheinander (keine zwei Programme). Und wenn ich da mal debugge und schon längst hinter der Zeile bin, wo die Daten in die Datenbank geschrieben wurden (incl. Update und was es da sonst noch so gibt) und dann Access öffne, um die Daten in der Datenbank zu kontrollieren, dann kommt es manchmal vor, dass die Daten in Access (in der Oberfläche von Access) nicht angezeigt werden. Dann muss man erst das C++-Programm schliessen oder aus der Funktion heraus laufen lassen, die Tabelle in der Oberfläche von Access schliessen und wieder öffnen und dann werden sie auch angezeigt.
-
Ente: http://www.nichtlustig.de/toondb/020702.html (Nein, kein Foto. Ein Comic. Herkunft meines Zitats) Aber ein Quitscheentchentatoo wäre auch was Schönes.
Jo, das sieht meinem Problem ziemlich ähnlich. Nur reicht bei mir das Beenden der Funktion nicht, es muss schon das Programm sein. Was die Access-Oberfläche anzeigt, wäre mir ja ziemlich wurscht, nur dass die Tabelle gesperrt ist und die Daten falsch am anderen Programm ankommen stört mich...
Vielleicht hat ja jemand nen Tipp für uns beide. Naja, lasst euch Zeit, ich komm erst morgen wieder.
-
Da fällt mir noch was ein:
Wie hast Du den Cursor eingestellt? Client- oder Serverseitig? Für Access sollte der auf serverseitig stehen.
-
Ist auf Client. Nun, dann versuch ichs mal. Was auch immer das ändert.
Edit: So, scheint jetzt zu klappen... danke!
-
Tja... kaum schreibt der Kollege ne bessere Testfunktion, muss man schon feststellen, dass der Fehler immer noch besteht.
Gibt es sonst noch Eigenschaften, die man in Bezug auf Access anpassen müsste?
-
Steht bei dem Testprogramm der Cursor auch Serverseitig?
Dies ist notwendig, Ursache ist die MS Jet-Engine. Diese kann (vermutlich) nicht mit Clientseitigen Cursorn umgehen.
Access ist sowieso nicht Multi-User-fähig. Und auch der gleichtzeitige schreibende Zugriff auf verschiedene Tabellen, bewirkt meinen Erfahrungen nach massive Probleme (zumindest bei Access 97).Was macht die verbesserte Testfunktion denn anders, als die vorherige Version?
-
Ich werde mal versuchen, den Kollegen abzufangen, wenn er hier vorbeirennt. (Tja, so läuft das hier.
) Dann kann ich ihn fragen, wie er den Cursor gesetzt hat.Gleichzeitig wird ja gar nicht auf die Tabelle zugegriffen. Wenn (theoretisch...) alles geschrieben wurde, wird in einer völlig anderen Tabelle ein Wert gesetzt, der dem anderen Programm signalisiert, dass die Daten da sind und ausgelesen werden können.
Die Testversion gibt einfach meiner Anwendung den Auftrag, die Daten in die Tabelle zu schreiben und liest sie dann aus. Bei den Testdaten weiß sie, wie viele Datensätze kommen müssen und gibt eine Meldung aus, wenn was fehlt. Fehlt nichts, wird kurz gewartet und neu begonnen. Davor musste man selbst jedes mal in der Tabelle schauen, wie voll sie ist.
-
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.