Office: (Office 2010) Laufzeitfehler 3197 ... weiterer Benutzer

GerryV · 3. April 2016

Guten Tag,
nach meinem Urlaub trat folgendes Problem auf, wobei der Code ca 7 Jahre lang ohne Probleme lief. Office Version 2010 DB aufgeteilt FE & BE und nun hier ein Teil des Codes wo der Fehler auftritt.

Code:

DoCmd.SetWarnings False
DoCmd.RunSQL "DELETE T_Stammdaten_F_Archiv.*" & _
" FROM T_Stammdaten_F_Archiv;"

DoCmd.RunSQL "INSERT INTO T_Stammdaten_F_Archiv" & _
" SELECT T_Stammdaten.*" & _
" FROM T_Stammdaten;"
DoCmd.SetWarnings True
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Der Fehler kommt bei dem zweiten Befehl INSERT INTO.

Fehlermeldung "Laufzeitfehler 3197: Das Microsoft-DBmodul hat den Vorgang angehalten, da Sie und ein weiterer Benutzer .......

Vielen Dank für jede Hilfe
Gerry

:)

avogt_at_home · 4. April 2016

Hallo,
lass doch das ganze in einer Transaktion laufen und reagiere bei Fehler.
Hier ein Beispiel:

Code:

Sub QueryTest()
Dim ws As DAO.Workspace
Dim db As DAO.Database

On Error GoTo QueryTest_Err

Set ws = DBEngine.Workspaces(0)
Set db = CurrentDb
With ws
.BeginTrans
db.Execute "DELETE T_Stammdaten_F_Archiv.* " & _
"FROM T_Stammdaten_F_Archiv", dbSeeChanges

db.Execute "INSERT INTO T_Stammdaten_F_Archiv " & _
"SELECT T_Stammdaten.* " & _
"FROM T_Stammdaten", dbSeeChanges
.CommitTrans
End With

Exit Sub

QueryTest_Err:
ws.Rollback
MsgBox "Datenänderung wurden nicht durchgeführt"
End Sub
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Siehe auch hier:
https://msdn.microsoft.com/de-de/lib.../ff197654.aspx

Btw: ich würde auf die DoCmd.RunSQL-Methode verzichten da die Execute-Methode des Datenbankobjektes wesentlich mehr Möglichkeiten und Vorteile besitzt z.B. durch die Angabe von Parametern.

Gruß Andreas

gpswanderer · 4. April 2016

Hallo,
wobei man auch die Notwendigkeit einer Archivtabelle für Stammdaten anzweifeln muss.

avogt_at_home · 5. April 2016

Hallo Klaus,
kennst ja den Spruch: "des Menschen Willen ist sein Himmelreich"

Gruß Andreas

jmc · 7. Januar 2021

von gpswanderer

Hallo,
wobei man auch die Notwendigkeit einer Archivtabelle für Stammdaten anzweifeln muss.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

Insbesondere so, wie es gelöst ist: ganze Archiv-Tabelle löschen und dann ganze Stammtabelle wieder reinschieben ...

Frage mich, WANN das gemacht wird? Jedesmal, wenn in den Stammdaten was ändert ??

Das könnte man auch einfacher haben, indem man einfach eine Kopie der Backend-DB macht.

Zum Fehler: 7 Jahre ohne Probleme heisst gar nichts, vielleicht hat tatsächlich jemand die Archiv-Tabelle offen? Einen Grund wird es ja (hoffentlich) geben, dass man dieses in derselben Backend hat.

Also wann wird wo/wie darauf zugegriffen?

Eventuell auch ein "Timing" Problem: wenn die Stammdatentabelle wächst und wächst, dann könnte ja sein, dass der Delete Befehl noch nicht vollständig abgearbeitet ist (auch Access arbeitet multi-tasking, ist ja die Jet-Engine, die den Delete effektiv ausführt) obschon der Code weiterläuft ?
z.b. mal einen sleep dazwischen schalten ?

Office: (Office 2010) Laufzeitfehler 3197 ... weiterer Benutzer

Laufzeitfehler 3197 ... weiterer Benutzer

Laufzeitfehler 3197 ... weiterer Benutzer

Laufzeitfehler 3197 ... weiterer Benutzer

Laufzeitfehler 3197 ... weiterer Benutzer - Similar Threads - Laufzeitfehler 3197 Benutzer

VBA:Laufzeitfehler beim Einlesen in Variable

Datenbank bleibt gesperrt - laccdb wird nicht gelöscht

Access Laufzeitfehler 3048

Laufzeitfehler 9 VBA

VBA Laufzeitfehler 9

[VBA] .Documents.Open -> Laufzeitfehler 91

Laufzeitfehler 3197