Fehler -2147217864, Die zum Aktualisieren angegebene Zeile wurde nicht gefunden. Einige Werte wurden seit dem letzten Lesen ggf. geändert.
Jürgen Schmitt
beim Update eines Recordsets tritt o.a. Fehler auf. Kann die Ursache
nicht finden.
z.B.
'Zuweisen SQL-String
sql = "SELECT * FROM Tabelle1;"
'Öffnen
Set RS = New ADODB.Recordset
With RS
.ActiveConnection = Conn
.CursorLocation = adUseClient
.LockType = adLockPessimistic
.source = sql
.Open
End With
For i = 1 To n 'Durchlaufen einer Schleife
With RS
.MoveFirst
sql = "Feld1='" & i & "'" 'Filter für alle Objekte mit Inhalt i
.Filter = sql 'Bringt jew. zw. 20-50 Datensätze
Do While Not .EOF 'Filter durchlaufen
debug.Print i, .Fields("ID") 'Kontrolle
'Jetzt z.B.
.Fields("Feld6") = .Fields("Feld6") + 1
If .Fields("Feld8") < 1 Then .Fields("Feld8") = i
x = i - .Fields("Feld10") - 1
If x > .Fields("Feld9") Then .Fields("Feld9") = x
.Fields("Feld13") = i
On Err Resume Next
Err.Clear
.Update 'Hier Fehler beim 2. Update eines Satzes
if Err then
Debug.Print Err, Err.Description
stop
end if
.MoveNext
Loop
End With
Next
Der Schleifenwert i filtert zw. 20-40 Datensätze aus dem Recordset,
wobei etliche Sätze mehrfach upgedatet werden.
Das 2. Update eines Satzes bringt den Fehler.
Weiss nicht, was ich da jetzt falsch mache.
Wäre wirklich dankbar für einen Tipp.
Gruss
Dieter Strassner
betrifft der Update auch deinen Primarykey der Tabelle? (gibt es den einen
PK dazu?)
Wird parallel zu dieser Schleufe (oder kurz vorher) über einen anderen Weg
(z.B. per "UPDATE mytable SET... WHERE ..") auch der Datensatz direkt
geändert?
--
Viele Grüße
Dieter
Rückfragen bitte nur in die Newsgroup!
EDV-Kommunikation Strassner e.K.
68623 Lampertheim
Internet: www.strassner.biz
Jürgen Schmitt
Es werden nur Felder geändert, nicht der PK selbst. PK ist das Feld ID
mit Autowert.
Vor Schleifenbeginn wird die Tabelle gelöscht.
'Tabelleninhalt Löschen
sql = "Delete Tabelle1.ID, Tabelle1.Feld1, Tabelle1.Feld2,....
FROM Tabelle1;"
Conn.Execute sql
Anschliessend aus anderen Tabellen neu erzeugt
'neu erzeugen
sql = "INSERT INTO Tabelle1 (ID, Feld1, Feld2, Feld3 .....) "
sql = sql & "SELECT Tabelle5.ID, Tabelle5.Feld1, Tabelle5.Feld2 ....
From Tabelle5 WHERE (((Tabelle5.StatKz)=1)) and (((Tabelle5.Feld9)= " &
x & "));"
Conn.Execute sql
Peter Götz
ich habe gestern und heute nochmal auf dieses
Posting geantwortet.
Sieht irgendjemand diese beiden Antworten?
Auf msnews.microsoft.com sind sie bisher nicht
zu finden.
Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)
Dieter Strassner
> Es werden nur Felder geändert, nicht der PK selbst. PK ist das Feld ID
> mit Autowert.
>
> Vor Schleifenbeginn wird die Tabelle gelöscht.
> 'Tabelleninhalt Löschen
> sql = "Delete Tabelle1.ID, Tabelle1.Feld1, Tabelle1.Feld2,....
> FROM Tabelle1;"
> Conn.Execute sql
>
> Anschliessend aus anderen Tabellen neu erzeugt
> 'neu erzeugen
> sql = "INSERT INTO Tabelle1 (ID, Feld1, Feld2, Feld3 .....) "
> sql = sql & "SELECT Tabelle5.ID, Tabelle5.Feld1, Tabelle5.Feld2 ....
> From Tabelle5 WHERE (((Tabelle5.StatKz)=1)) and (((Tabelle5.Feld9)= "
> & x & "));"
> Conn.Execute sql
Und dannach folgt:
>>> 'Zuweisen SQL-String
>>> sql = "SELECT * FROM Tabelle1;"
>>>
>>> 'Öffnen
>>> Set RS = New ADODB.Recordset
??
Oder davor?
Wenn davor, ist mit erklärlich. Wenn dannach nicht.
Hab in den Anfangsjahren meines Projektes auch diese Mischung aus
ADO-Befehlen und direkten SQL-Statements im Projekt gehabt. Ich erinnere
mich: Es klappte nicht immer....
Wenn der ADDB-rs von alten Daten ausgeht (Zeitpunkt der Erstellung), die
zwischenzeitlich per SQL-Statements geändert wurden, kann es schief gehen.
Meine Lösung: Aus den Änderungen des ADODB-rs UPDATE-Befehle formulieren und
ausführen. ADODB-rs schliessen und bei Bedarf neu laden. Mag nicht die
perfomanteste Lösung sein, aber eine die immer funktioniert (sofern der
Datenstatus korrekt in SQL-Befehle umgesetzt wurde).
Dieter Strassner
> Mal sehen, ob diese Antwort nun auf dem Server
> ankommt.
deine heutigen Posting von 9:41 und 10:16 sehe ich. Von gestern sehe ich von
Dir zu diesem Thread nichts.
--
Viele Gr��e
Dieter
R�ckfragen bitte nur in die Newsgroup!
Wilfried Dietrich
>
> ich habe gestern und heute nochmal auf dieses
> Posting geantwortet.
>
> Sieht irgendjemand diese beiden Antworten?
Nur von Heute 09:41.
Ich bemerke immer mal wieder, dass OE hinter dem
Newsgroup-Ordner eine bestimmte Zahl neuer Postings in
Klammern anzeigt, die geladen werden (sollen) aber dann
doch nicht da sind bzw. nicht angezeigt werden.
Das ist wieder dieses Phänomen der verbotenen Worte wie
z.B. ZYXmroF (bitte reverse lesen)
Gruß
Wilfried
Peter Götz
> deine heutigen Posting von 9:41 und 10:16 sehe ich. Von gestern sehe ich
> von Dir zu diesem Thread nichts.
Mein Posting von heute 9:41 sehe ich via ms.news.microsoft.com.
Das Posting von heute 10:16 ist jedoch bei mir bisher nicht
sichtbar.
Über welchen Server liest Du diese NG?
Helmut Meukel
im Gegensatz zu Dieter ist bei mir bisher nur dein heutiges Posting
von 9:41 angekommen und Dieters zwei von 9:49 und 10:23.
Welche Serveradresse verwendet ihr? Ich habe msnews.microsoft.com
eingestellt und verwende Windows Mail unter Vista.
Viele Gr��e
Helmut.
"Dieter Strassner" <ne...@microsoft.com> schrieb im Newsbeitrag
news:%23MJVIX0...@TK2MSFTNGP06.phx.gbl...
Peter Götz
> Hallo Peter, hallo Dieter,
>
> im Gegensatz zu Dieter ist bei mir bisher nur dein heutiges Posting von
> 9:41 angekommen und Dieters zwei von 9:49 und 10:23.
> Welche Serveradresse verwendet ihr? Ich habe msnews.microsoft.com
> eingestellt und verwende Windows Mail unter Vista.
Ich lese die NGs via msnews.microsoft.com mit
Outlook-Express und Windows XP
Windows-Mail und Vista
Windows Live Mail und Windows 7
auf unterschiedlichen Rechnern, jeodch mit den gleichen
Ergebnissen (fehlende Postings).
Dieter Strassner
> Über welchen Server liest Du diese NG?
ich lese die NGs ebenfalls via msnews.microsoft.com mit Outlook-Express (6)
und Windows XP, SP3
--
Viele Grüße
Dieter
Rückfragen bitte nur in die Newsgroup!
Peter Götz
> deine heutigen Posting von 9:41 und 10:16 sehe ich. Von gestern sehe ich
> von Dir zu diesem Thread nichts.
Ich habe gerade mal die NG auf einem komplett neu
eingerichteten Rechner mit XP und OE6 eingelesen.
Auch hier sehe ich mein Posting von heute 10:16
nicht.
Auch über das Web-Interface
sehe ich mein Posting von heute 10:16 nicht.
Ingo Moch
"Peter Götz" schrieb:
> ich habe gestern und heute nochmal auf dieses
> Posting geantwortet.
>
> Sieht irgendjemand diese beiden Antworten?
> Auf msnews.microsoft.com sind sie bisher nicht
> zu finden.
Da scheint nichts angekommen zu sein. Ich lese
meine NGs ueber vier Server und es ist nichts
zu sehen.
Ingo
Thorsten Albers
<ONQX6$zxKHA...@TK2MSFTNGP04.phx.gbl>...
> ich habe gestern und heute nochmal auf dieses
> Posting geantwortet.
>
> Sieht irgendjemand diese beiden Antworten?
> Auf msnews.microsoft.com sind sie bisher nicht
> zu finden.
Hatten wir schon einmal auf dem MS-Newsserver in diversen Newsgroups.
Schien meiner Erinnerung nach ein Problem mit bestimmten Zeichenfolgen in
Postings zu sein, die fälschlicherweise für böse, böse Skripte gehalten
wurden o.ä.
--
Thorsten Albers
albers (a) uni-freiburg.de
Peter Götz
> Hatten wir schon einmal auf dem MS-Newsserver in
> diversen Newsgroups.
Ja, das Problem ist nicht neu und taucht immer wieder
mal auf. Nachdem das Problem das letzte Mal behoben
war, war auch eine geraume Zeit Ruhe. Nun aber
scheint das Problem wieder verstärkt aufzutreten.
In den letzten Tagen sind mehrere meiner Postings,
nicht nur in dieser NG, im Nirwana verschwunden.
Da hat vermutlich wieder mal jemand an irgendwelchen
Filtern herumgedreht.
> Schien meiner Erinnerung nach ein Problem mit bestimmten
> Zeichenfolgen in Postings zu sein, die fälschlicherweise für
> böse, böse Skripte gehalten wurden o.ä.
Das wird es vermutlich auch diesmal wieder sein, da
vor allem Postings betroffen sind, in denen irgendwelcher
Beispielcode enthalten ist.
Ich habe das Problem an MS gemeldet. Mal sehen, ob und
wann es behoben wird.
Peter Götz
Und noch ein Versuch einer Antwort.
Ich habe vorgestern, gestern und heute bereits mehrfach
auf Dein Posting geantwortet, aber leider sind diese
Antworten verschwunden und bis jezt nicht zu sehen.
Ich versuche es deshalb nochmal mit einer kleineren
Teilantwort.
Mit
.ActiveConnection = Conn
weist Du Deinem RS nicht einen Verweis auf Dein
bestehendes Connectionobjekt (Conn) zu, sondern
erzeugst eine neue Instanz eines Connectionobjektes.
RS.ActiveConnection erwartet einen Verweis auf ein
Objekt (ADODB.Connection) weshalb die Zeile so
aussehen müsste:
Set .ActiveConnection = Conn
Das fehlende Set bewirkt, dass VB davon ausgeht,
dass es sich nicht um eine Zuweisung eines Objekt-
verweises handelt, schaut sich die Default-Eigenschaft
von Conn an, das ist der ConnectionString, erzeugt
damit eine neue Instanz einer ADODB.Connection
und übergibt Deinem RS dann einen Verweis auf
diese neue (zweite) Connection.
Damit hast Du nun zwei Connection-Objekte mit zwei
separaten Datenpuffern, deren Daten nicht mehr in
jedem Fall synchron sind.
CursorLocation = adUseClient
und
LockType = adLockPessimistic
passen nicht zusammen. ADO macht aus
Deinem adLockPessimistic implizit ein
adLockBatchOptimistic.
Dein Recordset sollte diese Eigenschaften haben:
CursorLocation = adUseClient
CursorType = adOpenStatic
LockType = adLockBatchOptimistic
oder
LockType = adLockOptimistic
Mal sehen, ob diese Antwort nun auf dem Server
ankommt.
Gruß aus St.Georgen
Peter Götz
ADODB.Recordset
.ActiveConnection = Conn
Set .ActiveConnection = Conn
Dies ist ein Test wg. verschwundener Postings.
Wolfgang Backes
>Guten Tag zusammen,
>beim Update eines Recordsets tritt o.a. Fehler auf. Kann die Ursache
>nicht finden.
Hallo Jürgen,
dieser Fehler hat mich schon mehrmals zur Verzweiflung gebracht. Er
trat auf beim Zugriff auf eine Access-Datenbank über ein Component One
True Data Control. Er verschwand, nachdem ich "CursorLocation =
adUseClient" auf CursorLocation = adUseServer" abgeändert hatte.
Keine Ahnung, was da intern passiert, aber der Fehler ließ sich
regelmäßig auf diese Weise beseitigen. Vielleicht kannst Du mit diesem
Hinweis etwas anfangen.
Gruß
Wolfgang
Peter Götz
>>beim Update eines Recordsets tritt o.a. Fehler auf.
> >Kann die Ursache nicht finden.
>
> Hallo Jürgen,
>
> dieser Fehler hat mich schon mehrmals zur Verzweiflung
> gebracht. Er trat auf beim Zugriff auf eine Access-Datenbank
> über ein Component One True Data Control. Er verschwand,
> nachdem ich "CursorLocation = adUseClient" auf
> CursorLocation = adUseServer" abgeändert hatte.
Serverseitige Cursor sind beachtliche Ressourcenfresser
und nicht unbedingt das geeignete Mittel solche Zugriffskonflikte
zu lösen.
> Keine Ahnung, was da intern passiert, aber der Fehler ließ sich
> regelmäßig auf diese Weise beseitigen. Vielleicht kannst Du
> mit diesem Hinweis etwas anfangen.
Wenn eine zum aktualisieren angegebene Zeile nicht gefunden
wird, bedeutet dies ganz einfach, dass eines oder mehrere Felder,
die in der Where-Klausel des Update-Commands stehen, nicht
mehr mit den in der Where-Klausel angegebenen Werten
übereinstimmen. Das ist z.B. dann der Fall, wenn der Datensatz
seit dem letzten Einlesen von anderer Stelle aus in den betr.
Feldern verändert worden ist und damit die Bedingungen der
Where-Klausel eben nicht mehr erfüllt sind.
In Jürgens Code gibt es ein weiteres Problem.
Statt seinem Recordset RS einen Verweis auf ein bereits
vorhandenes ConnectionObjekt zu übergeben, erstellt er
implizit mit
RS.ActiveConnection = Conn
ein neues Connectionobjekt, weil das bei Objektverweisen
voranzustellende "Set" fehlt. Damit arbeitet er über
zwei verschiedene Connectionobjekte mit zwei verschiedenen
Datenpuffern, deren Dateninhalte nicht mehr in jedem Fall
synchron sind.
Aiuch die Einstellungen CursorLocation, CursorType und
LockType in Jürgens Code sind unpassend bzw. fehlen.
Sie sollten so aussehen:
CursorLocation = adUseClient
CursorType = adOpenStatic
LockType = adLockOptimistic
oder
LockType = adLockBatchOptimistic
Wolfgang Backes
...
>Serverseitige Cursor sind beachtliche Ressourcenfresser
>und nicht unbedingt das geeignete Mittel solche Zugriffskonflikte
>zu lösen.
Hallo Peter,
das glaube ich gerne, aber in meinem Fall war es die ultima ratio. Ich
konnte trotz intensiver Suche keinen Fehler im Code finden und habe
dann aus Verzweiflung alle Properties des Controls nacheinander
verändert (wobei ich nicht weiß, wozu die alle gut sind, so tief bin
ich bisher in diese Materie noch nicht eingestiegen -- und ich hoffe,
dass mir das erspart bleibt...)
Viele Grüße
Wolfgang
Peter Götz
> Vor Schleifenbeginn wird die Tabelle gelöscht.
> 'Tabelleninhalt Löschen
> sql = "Delete Tabelle1.ID, Tabelle1.Feld1, Tabelle1.Feld2,....
> FROM Tabelle1;"
> Conn.Execute sql
>
> Anschliessend aus anderen Tabellen neu erzeugt
> 'neu erzeugen
> sql = "INSERT INTO Tabelle1 (ID, Feld1, Feld2, Feld3 .....) "
> sql = sql & "SELECT Tabelle5.ID, Tabelle5.Feld1, Tabelle5.Feld2 .... From
> Tabelle5 WHERE (((Tabelle5.StatKz)=1)) and (((Tabelle5.Feld9)= " & x &
> "));"
> Conn.Execute sql
Du hast wg. des fehlenden "Set" bei der Zuweisung von RS.ActiveConnection
in einem früheren Schritt ein Recordset über eine zweite, von Conn
unabhängige Instanz eines ConnectionObjektes erzeugt.
Dein hier gezeigtes Conn.Execute sql führst Du jedoch über die
erste Instanz des ConnectionObjektes aus. Mit Deinem Insert-Command
werden Datensätze mit neuen Autowerten erzeugt, die keinerlei Beziehung
mehr zu den Datensätzen haben, die im Datenpuffer des anderen,
implizit erzeugten ConnectionObjektes stehen.
Peter Götz
nachdem meine Antwortpostings mit div. Korrekturen
zu Deinem Beispielcode im Nirvana verschweunden
sind, versuche ich es nun nochmals.
> Guten Tag zusammen,
> beim Update eines Recordsets tritt o.a. Fehler auf. Kann die Ursache nicht
> finden.
>
> z.B.
>
> 'Zuweisen SQL-String
> sql = "SELECT * FROM Tabelle1;"
>
> 'Öffnen
> Set RS = New ADODB.Recordset
> With RS
> .ActiveConnection = Conn
Mit der vorstehenden Zeile weist Du Deinem Recordset
nicht einen Verweis auf Dein bereits bestehendes
ConnectionObjekt zu, sondern erstellst eine weitere,
neue Instanz eines ConnectionObjektes.
Die Eigenschaft ActiveConnection des Recordsets
erwartet einen Verweis auf ein ConnectionObjekt,
weshalb die Zuweisung mit
Set .ActiveConnection = Conn
erfolgen muss. Ohne Set geht VB davon aus, dass
es sich um keinen Objektverweis handelt, liest deshalb
die Default-Eigenschaft (ConnectionString) des bereits
bestehenden ConnectionObjektes, erstellt damit
eine neue Instanz eines ConnectionObjektes und
übergibt Deinem Recordset einen Verweis aus diese
neue Instanz.
Damit hast Du zwei ConnectionObjekte mit jeweils
einem eigenen Datenpuffer, deren Daten nicht zu
jederzeit synchron sind. Das bedeutet, dass Änderungen,
welche Du über die eine Connection machst nicht ohne
Weiteres über die zweite Connection sichtbar werden.
> .CursorLocation = adUseClient
> .LockType = adLockPessimistic
Die Kombination der beiden vorstehenden Eigenschafts-
einstellungen adUseClient und adLockPessimistic ist
technisch nicht möglich, weshalb VB bzw. ADO aus
Deinem adLockPessimistic implizit ein adLockBatchOptimistic
oder adLockOptimistic macht. Schau Dir mal im Debug- oder
Überwachungsfenster an, welche Einstellungen Dein RS
tatsächlich hat.
Du solltest Dein RS so konfigurieren
RS.CursorLocation = adUseClient
RS.CursorType = adOpenStatic
RS.LockType = adLockOptimistic
oder
RS.LockType = adLockBatchOptimistic
Bei LockType adLockOptimistic werden Änderungen an
Datensätzen mit dem nächsten RS.Update bzw. implizit
beim Wechsel zu einem anderen Datensatz in die
entsprechende DB-Tabelle übernommen.
Bei LockType adLockBatchOptimistic werden Änderungen
an Datensätzen mit den nächsten RS.Update bzw.
implizit beim Wechsel zu einem anderen Datensatz
in Dein lokales Recordset übernommen und erst mit
dem nächsten RS.UpdateBatch tatsächlich in die
DB übertragen.
Aus Deinem Code ist leider nicht ersichtlich, welche
Datentypen die Felder Deines Recordsets haben
und auch nicht ob und welches Feld als Primärschlüssel
definiert ist. Um einen möglichen Fehler zu erkennen,
müsste man diese Informationen haben.
> Der Schleifenwert i filtert zw. 20-40 Datensätze aus dem Recordset, wobei
> etliche Sätze mehrfach upgedatet werden.
> Das 2. Update eines Satzes bringt den Fehler.
Das bedeutet, dass der betr. Datensatz seit dem letzen
Einlesen in Dein RS in einem oder mehreren Feldern so
verändert wurde, dass er nicht mehr eindeutig identifiziert
werden kann. Auch ein fehlender Primärschlüssel kann
die Ursache für diesen Fehler sein.
> Weiss nicht, was ich da jetzt falsch mache.
> Wäre wirklich dankbar für einen Tipp.
Ursache für Dein Problem sind vermutlich Deine
beiden ConnectionObjekte, deren Daten nicht
synchron sind (siehe hierzu Antowort auf Dein Posting
vom 19.03.2010).