Access, ADO, Datenverlust,
-
Hallo,
eine Anwendung schreibt über ADO Daten in eine Access-Tabelle*. Hierzu wird sie geöffnet, geleert, beschrieben und wieder geschlossen. Diese Daten sollen von einer anderen Anwendung wieder ausgelesen werden, Access ist also sozusagen eine Schnittstelle zwischen den Programmen*. Nun habe ich jedoch das Problem, dass ab und zu diese Daten nicht komplett sind. Der Vorgang des Beschreibens ist immer der Selbe, die Daten auch. Öffnet man während die Anwendung läuft (Tabelle aber schon wieder freigegeben) Access und sieht sich die Daten an, sind weniger Datensätze vorhanden als es sein sollten. Versucht die zweite Anwendung, an die Daten zu kommen, sind diese nicht nur unvollständig sondern die Tabelle ist auch noch gesperrt. Schließt man jedoch die Anwendung und versucht den Zugriff nochmal, sind die Daten plötzlich wieder da und die Tabelle ist beschreibbar. Nun, in der Anwendung sieht alles richtig aus - kein Post bringt eine Exception, die Tabelle ist geschlossen sobald der Befehl dazu kam und fragt man nach dem Beschreiben der Tabelle die Anzahl der Datensätze ab ist diese auch korrekt, man kann sogar die Tabelle vollständig anzeigen lassen. Nun, es wäre mir neu, dass ADO Daten zwischenspeichert und auch sonst fällt mir nichts ein. Also denke ich, dass es an Access liegt. Kann das jemand bestätigen oder hat jemand - noch besser - eine Lösung für das Problem? (Ich bin gerne bereit, Nachfragen zu beantworten, sofern sie sich nicht auf die Ente an meinem Hintern beziehen.
)*War nicht meine Idee, ich finde es dämlich, kann aber nichts dagegen tun.
-
Access ist keine echte Datenbank. Was erwartest Du da.
Du solltest die Tabelle, so lange sie beschrieben wird, exklusiv sperren. Ansonsten mußt Du dir wohl über ein 3-schichtiges Modell Gedanken machen.
-
Du hast eine Ente am Hintern ?
Eine Lösung kenne ich nicht, aber bestätigen kann ich das. Was man in Access sieht und was wirklich drin ist muss nicht unbedingt das selbe sein, da kommt es manchmal vor, dass die Anzeige von Access noch nicht so weit ist und weniger oder etwas veraltetes anzeigt.
Ich benutze übrigens ODBC, aber da kommt das auch vor.
-
Erwarten tu ich gar nichts. Ich hoffe.
Nun, sperren während dem Schreiben ist natürlich eine gute Idee. Nur würde das nichts helfen. Der Fehler tritt auf, wenn ich Schreiben und Auslesen nacheinander mache. Ich habe es immer nacheinander gemacht, ansonsten könnte ich das Problem ja verstehen.
Dein Tipp mit dem 3-Schicht-Modell geht wohl auch in die Richtung des gleichzeitigen Zugriffs, oder?
-
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...