Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Fehler 3218 Aktualisierung nicht möglich; momentan gesperrt.
367 views
Skip to first unread message
Lutz
Oct 15, 2013, 4:32:00 AM10/15/13
to
5 Jahre spï¿œter und ich habe dasselbe Problem.
Damals half nur ein Workaround - eine Lï¿œsung gab es nicht!
Diesmal geht es um eine simple Aktualisierungsabfrage innerhalb einer
Transaktion.
sql = "UPDATE a_BewertungBerech1 SET InvMP=BerInvMP" _
& " WHERE Nz(InvNEU,False)=True"
db.Execute sql, dbFailOnError
Die Abfrage ist auf nur EINER Tabelle. BerInvMP ist ein berechnetes Feld.
SELECT t_InventurPreisAkt.InvNr2, t_InventurPreisAkt.InvMP1,
t_InventurPreisAkt.InvMP2,
IIf([InvMP1]>0,IIf([InvMP1]<[InvMP2],[InvMP1],[InvMP2]),[InvMP2]) AS
BerInvMP, t_InventurPreisAkt.InvMP, t_InventurPreisAkt.InvBeST,
t_InventurPreisAkt.InvBeVM, t_InventurPreisAkt.InvBeVVM,
(t_InventurPreisAkt!InvBeST*3)+(t_InventurPreisAkt!InvBeVM*2)+(t_InventurPreisAkt!InvBeVVM*1)
AS BerInvDB, t_InventurPreisAkt.InvDB, t_InventurPreisAkt.InvNEU
FROM t_InventurPreisAkt;
Das Update ist Teil einer komplexeren Operation deshalb in einer
Transaktion. Der Ablauf steigt immer an dieser Stelle aus.
Fehler 3128 - Aktualisierung nicht mï¿œglich; momentan gesperrt.
Das Datenbank-Objekt zeigt direkt vor der Ausfï¿œhrung keine weiteren
geï¿œffneten Recordsets an. Ich arbeite alleine - niemand anders kann an
den entsprechenden Daten dran sein.
Lasse ich die Operation allerdings nur bis davor laufen und fï¿œhre den
Update-Select per Hand auf der Datenbank aus funktioniert er.
Ich habe testweise die Transaktion weggelassen, das Workspace-Objekt
eigens erstellt. Ich habe die Updates versucht auf der Tabelle
auszufï¿œhren - nichts hilft.
Hat irgendjemand eine Idee???
Lutz
Am 20.06.2008 12:25, schrieb Lutz Uhlmann:
> Access 2003 Projekt FE + BE
>
> Bei mir kam der Fehler 3218 und machte mir einen Strich durch meinen
> Programm-Ablauf
> Der Fehler tritt bei einer grￜￜeren Datenbearbeitung im Code auf, welche ich
> wegen des Umfangs in eine Transaktion gesteckt habe.
> Fï¿œr die Bearbeitung ï¿œffne ich das BE direkt. Ich arbeite allein auf der
> Datenbank, kann also nicht an einem 2. Benutzer liegen.
>
> In folgendem Code tritt ziemlich am Ende der ganzen Operation der Fehler
> 3218 auf.
>
> sql = "SELECT * FROM t_Material WHERE MatMenge=0"
> Set rsmat = db.OpenRecordset(sql, dbOpenDynaset)
> Do Until rsmat.EOF
> lMatID = Nz(rsmat!MatID, 0)
> sql = "DELETE * FROM t_MaterialFrist WHERE MatID=" & lMatID
> db.Execute sql, dbFailOnError
> sql = "DELETE * FROM t_MaterialRes WHERE MatID=" & lMatID
> db.Execute sql, dbFailOnError
> sql = "DELETE * FROM t_MatDokumente WHERE ANL_ID=" & lMatID
> db.Execute sql, dbFailOnError
> sql = "DELETE * FROM t_MatNotiz WHERE ANL_ID=" & lMatID
> db.Execute sql, dbFailOnError
> sql = "DELETE * FROM t_MatTechnisch WHERE ANL_ID=" & lMatID
> db.Execute sql, dbFailOnError
>
> rsmat.MoveNext
> Loop
> rsmat.Close
> Set rsmat = Nothing
>
> DBEngine.Idle dbRefreshCache '(???)
>
> sql = "DELETE * FROM t_Material WHERE MatMenge=0"
> db.Execute sql, dbFailOnError '<---- Fehler 3218
>
> Bei diesem letzten Execute kommt der Fehler. Habe probiert ob ich mit
> DBEngine.Idle dbRefreshCache vielleicht die vorherige Aktion auf dieser
> Tabelle abschliessen kann. hat nicht geholfen.
> Beheben kann ich das zwar, indem ich das Lï¿œschen des Datensatzes mit
> "rsmat.delete" in die Schleife verlege, aber prinzipiell mￜￜte doch auch die
> obige Variante funktionieren? Bzw wie kann man die zum Funktionieren
> bringen??? Der Fehler muￜ ja irgendeine Ursache haben ...
>
> Lutz
>
>
Damals half nur ein Workaround - eine Lï¿œsung gab es nicht!
Diesmal geht es um eine simple Aktualisierungsabfrage innerhalb einer
Transaktion.
sql = "UPDATE a_BewertungBerech1 SET InvMP=BerInvMP" _
& " WHERE Nz(InvNEU,False)=True"
db.Execute sql, dbFailOnError
Die Abfrage ist auf nur EINER Tabelle. BerInvMP ist ein berechnetes Feld.
SELECT t_InventurPreisAkt.InvNr2, t_InventurPreisAkt.InvMP1,
t_InventurPreisAkt.InvMP2,
IIf([InvMP1]>0,IIf([InvMP1]<[InvMP2],[InvMP1],[InvMP2]),[InvMP2]) AS
BerInvMP, t_InventurPreisAkt.InvMP, t_InventurPreisAkt.InvBeST,
t_InventurPreisAkt.InvBeVM, t_InventurPreisAkt.InvBeVVM,
(t_InventurPreisAkt!InvBeST*3)+(t_InventurPreisAkt!InvBeVM*2)+(t_InventurPreisAkt!InvBeVVM*1)
AS BerInvDB, t_InventurPreisAkt.InvDB, t_InventurPreisAkt.InvNEU
FROM t_InventurPreisAkt;
Das Update ist Teil einer komplexeren Operation deshalb in einer
Transaktion. Der Ablauf steigt immer an dieser Stelle aus.
Fehler 3128 - Aktualisierung nicht mï¿œglich; momentan gesperrt.
Das Datenbank-Objekt zeigt direkt vor der Ausfï¿œhrung keine weiteren
geï¿œffneten Recordsets an. Ich arbeite alleine - niemand anders kann an
den entsprechenden Daten dran sein.
Lasse ich die Operation allerdings nur bis davor laufen und fï¿œhre den
Update-Select per Hand auf der Datenbank aus funktioniert er.
Ich habe testweise die Transaktion weggelassen, das Workspace-Objekt
eigens erstellt. Ich habe die Updates versucht auf der Tabelle
auszufï¿œhren - nichts hilft.
Hat irgendjemand eine Idee???
Lutz
Am 20.06.2008 12:25, schrieb Lutz Uhlmann:
> Access 2003 Projekt FE + BE
>
> Bei mir kam der Fehler 3218 und machte mir einen Strich durch meinen
> Programm-Ablauf
> Der Fehler tritt bei einer grￜￜeren Datenbearbeitung im Code auf, welche ich
> wegen des Umfangs in eine Transaktion gesteckt habe.
> Fï¿œr die Bearbeitung ï¿œffne ich das BE direkt. Ich arbeite allein auf der
> Datenbank, kann also nicht an einem 2. Benutzer liegen.
>
> In folgendem Code tritt ziemlich am Ende der ganzen Operation der Fehler
> 3218 auf.
>
> sql = "SELECT * FROM t_Material WHERE MatMenge=0"
> Set rsmat = db.OpenRecordset(sql, dbOpenDynaset)
> Do Until rsmat.EOF
> lMatID = Nz(rsmat!MatID, 0)
> sql = "DELETE * FROM t_MaterialFrist WHERE MatID=" & lMatID
> db.Execute sql, dbFailOnError
> sql = "DELETE * FROM t_MaterialRes WHERE MatID=" & lMatID
> db.Execute sql, dbFailOnError
> sql = "DELETE * FROM t_MatDokumente WHERE ANL_ID=" & lMatID
> db.Execute sql, dbFailOnError
> sql = "DELETE * FROM t_MatNotiz WHERE ANL_ID=" & lMatID
> db.Execute sql, dbFailOnError
> sql = "DELETE * FROM t_MatTechnisch WHERE ANL_ID=" & lMatID
> db.Execute sql, dbFailOnError
>
> rsmat.MoveNext
> Loop
> rsmat.Close
> Set rsmat = Nothing
>
> DBEngine.Idle dbRefreshCache '(???)
>
> sql = "DELETE * FROM t_Material WHERE MatMenge=0"
> db.Execute sql, dbFailOnError '<---- Fehler 3218
>
> Bei diesem letzten Execute kommt der Fehler. Habe probiert ob ich mit
> DBEngine.Idle dbRefreshCache vielleicht die vorherige Aktion auf dieser
> Tabelle abschliessen kann. hat nicht geholfen.
> Beheben kann ich das zwar, indem ich das Lï¿œschen des Datensatzes mit
> "rsmat.delete" in die Schleife verlege, aber prinzipiell mￜￜte doch auch die
> obige Variante funktionieren? Bzw wie kann man die zum Funktionieren
> bringen??? Der Fehler muￜ ja irgendeine Ursache haben ...
>
> Lutz
>
>
Lutz
Oct 15, 2013, 7:18:03 AM10/15/13
to
Ich habe jetzt das ganze auf Recordset-Loops umgestellt als Workaround.
Er kommt auch relativ gut durch die einzelnen Updates durch.
Spï¿œter in der Operation bekomme ich nun aber den Fehler
3052 - Anzahl der Dateisperrungen ï¿œberschritten.
wï¿œhrend eines rs.Update Aufrufes.
Ich vermute, daￜ beide Fehler zusammenhￜngen und Auswirkung
einundderselben Ursachen sind.
Kï¿œnnten die Sperren Probleme bereiten? Auch innerhalb einundderselben
Transaktion obwohl die entsprechenden Recordsets schon wieder
geschlossen wurden?
Was kann man in die Richtung vorbeugend tun?
Lutz
P.S. Habe noch einen Artikel zum ursprￜnglichen Thema gefunden. Weiￜ
aber nicht inwieweit der damit zu tun hat. Vielleicht ist es ein
Jet-Problem?
habe es noch nciht ausprobiert. Ich wollte jetzt nicht alles auf ADO
umstellen, da ich im Moment keine Zeit dafï¿œr habe.
http://support.microsoft.com/kb/331594/en-us
Er kommt auch relativ gut durch die einzelnen Updates durch.
Spï¿œter in der Operation bekomme ich nun aber den Fehler
3052 - Anzahl der Dateisperrungen ï¿œberschritten.
wï¿œhrend eines rs.Update Aufrufes.
Ich vermute, daￜ beide Fehler zusammenhￜngen und Auswirkung
einundderselben Ursachen sind.
Kï¿œnnten die Sperren Probleme bereiten? Auch innerhalb einundderselben
Transaktion obwohl die entsprechenden Recordsets schon wieder
geschlossen wurden?
Was kann man in die Richtung vorbeugend tun?
Lutz
P.S. Habe noch einen Artikel zum ursprￜnglichen Thema gefunden. Weiￜ
aber nicht inwieweit der damit zu tun hat. Vielleicht ist es ein
Jet-Problem?
habe es noch nciht ausprobiert. Ich wollte jetzt nicht alles auf ADO
umstellen, da ich im Moment keine Zeit dafï¿œr habe.
http://support.microsoft.com/kb/331594/en-us
Ulrich Möller
Oct 15, 2013, 8:34:13 AM10/15/13
to
es sieht so aus, als wolltest du einen Massenupdate machen.
Transaktionen muￜ man sehr bedacht einsetzen, denn ￜblicherweise will
man damit eine Logik wie "Alles oder gar nichts" umsetzen.
Stelle die Transaktionen in kleinere Update Einheiten zusammen und
versuche sie nur dort zu gebrauchen, wo sie einen Sinn ergeben. Niemals
das "Commit" vergessen!!!. Dieses ist ein Fehler, der immer gerne
gemacht wird. Solange kein Commit gemacht wird, bleiben die geï¿œnderten
Datensï¿œtze fï¿œr gesperrt , wird wohl auch in Access so sein.
ï¿œber wie viele Records in den Tabellen reden wir?
Grￜￜe
Ulrich
Lutz
Oct 15, 2013, 10:33:07 AM10/15/13
to
Am 15.10.2013 14:34, schrieb Ulrich Mï¿œller:
> Hallo Lutz,
>
> es sieht so aus, als wolltest du einen Massenupdate machen.
> Transaktionen muￜ man sehr bedacht einsetzen, denn ￜblicherweise will
> man damit eine Logik wie "Alles oder gar nichts" umsetzen.
> Stelle die Transaktionen in kleinere Update Einheiten zusammen und
> versuche sie nur dort zu gebrauchen, wo sie einen Sinn ergeben. Niemals
> das "Commit" vergessen!!!. Dieses ist ein Fehler, der immer gerne
> gemacht wird. Solange kein Commit gemacht wird, bleiben die geï¿œnderten
> Datensï¿œtze fï¿œr gesperrt , wird wohl auch in Access so sein.
Nunja, es handelt sich um Buchungen. Die mï¿œssen auch konsistent sein.
> Hallo Lutz,
>
> es sieht so aus, als wolltest du einen Massenupdate machen.
> Transaktionen muￜ man sehr bedacht einsetzen, denn ￜblicherweise will
> man damit eine Logik wie "Alles oder gar nichts" umsetzen.
> Stelle die Transaktionen in kleinere Update Einheiten zusammen und
> versuche sie nur dort zu gebrauchen, wo sie einen Sinn ergeben. Niemals
> das "Commit" vergessen!!!. Dieses ist ein Fehler, der immer gerne
> gemacht wird. Solange kein Commit gemacht wird, bleiben die geï¿œnderten
> Datensï¿œtze fï¿œr gesperrt , wird wohl auch in Access so sein.
Bei einem Fehler muss alles zurï¿œckgerollt werden!
Ich seh auch keine richtige Mï¿œglichkeit das in Einzelschritte zu zerlegen.
Die gesamte Operation erfolgt in einer Funktion welche Boolean zurï¿œckgibt.
Dieser Aufruf ist durch die Transaktion gekapselt und je nach Ergebnis
erfolgt ein Commit oder Rollback. Das ist eigentlich sicher was das
Beenden der Transaktion angeht.
> ï¿œber wie viele Records in den Tabellen reden wir?
Einmal um die 300 Positionen, fï¿œr die es je ca. 7, 8 Buchungen gibt.
Dazu nochmal ein paar 1000 Positionen mit 2 Buchungen.
Der Einfachheit halber mache ich die 1. Buchung fï¿œr die 300 Positionen
in einem Rutsch, dann die 2. Buchung usw. Logisch zusammengehï¿œrend sind
aber die Buchungen.
Schwierig zu erklï¿œren.
Ich schau es mir nochmal an, ob ich dort bestimmte Teile irgendwie in
mehrere Transaktionen teilen kann.
Aber den 3218-Fehler hatte ich auch mit auskommentierter Transaktion.
Deswegen bin ich da bissl unsicher, was die genaue Ursache ist.
Lutz
Ulrich Möller
Oct 15, 2013, 11:30:02 AM10/15/13
to
nï¿œmlich alle Buchungen zu einer Position in eine Transaktion abwickeln -
wenn das notwendig ist. Jede Transaktion mit einem Commit abschlieï¿œen,
hierbei aber den Fehlerausgang mit einem Rollback nicht vergessen, falls
etwas nicht geklappt hat, d.h alle Buchungen pro Position wurden
durchgefï¿œhrt oder keine!
Kontrolliere in den Optionen die Einstellung fï¿œr die Datensatzsperren ->
Standard bei Datensatzsperren = bearbeiteter Datensatz.
Beim Fehler 3128 hat sich wahrscheinlich einen semantischer Fehler
eingeschlichen. Irgendwo wird ein Datensatz geï¿œndert, ein Recordset
exklusiv aufgemacht oder schlicht ein Recordset.Close vergessen.
Ulrich
Ingo Moch
Oct 17, 2013, 4:09:39 PM10/17/13
to
Lutz wrote:
> 5 Jahre spï¿œter und ich habe dasselbe Problem.
> Damals half nur ein Workaround - eine Lï¿œsung gab es nicht!
>
>
> Diesmal geht es um eine simple Aktualisierungsabfrage
> innerhalb einer Transaktion.
>
> sql = "UPDATE a_BewertungBerech1 SET InvMP=BerInvMP" _
> & " WHERE Nz(InvNEU,False)=True"
> db.Execute sql, dbFailOnError
>
> [...]
> 5 Jahre spï¿œter und ich habe dasselbe Problem.
> Damals half nur ein Workaround - eine Lï¿œsung gab es nicht!
>
>
> Diesmal geht es um eine simple Aktualisierungsabfrage
> innerhalb einer Transaktion.
>
> sql = "UPDATE a_BewertungBerech1 SET InvMP=BerInvMP" _
> & " WHERE Nz(InvNEU,False)=True"
> db.Execute sql, dbFailOnError
>
>
> Das Update ist Teil einer komplexeren Operation deshalb
> in einer Transaktion. Der Ablauf steigt immer an dieser
> Stelle aus. Fehler 3128 - Aktualisierung nicht mï¿œglich; momentan
> gesperrt.
Du kannst die Anzahl der mï¿œglichen Sperren erhoehen.
> Das Update ist Teil einer komplexeren Operation deshalb
> in einer Transaktion. Der Ablauf steigt immer an dieser
> Stelle aus. Fehler 3128 - Aktualisierung nicht mï¿œglich; momentan
> gesperrt.
Standard ist 9500.
DAO:
DBEngine.SetOption dbMaxLocksPerFile, 25000
ADO:
Dim con As ADODB.Connection
[Parameter des Connection-Objekts setzen]
con.Open
con.Properties("Jet OLEDB:Max Locks Per File") = 25000
Allerdings bedeutet das, dass entsprechend mehr Speicher
reserviert wird.
Ingo
0 new messages