Abfrage ist beschädigt. Error-Code 3340 in Access2013
Hallo Foren-Mitglieder,
ich hätte da mal ein Problem......
Seit heute am Morgen (13.11.2019) erhalte ich die Fehlermeldung "Abfrage '' ist beschädigt" unter meiner Access 2013-Applikation. Bis gestern lief alles wunderbar und ich habe auch nichts verändert bzw.Installiert auf meinem Rechner. Das Office-Paket habe ich bereits "repariert", allerdings ohne Erfolg bei der Fehlermeldung.
Hat jemand so etwas schon mal gehabt bzw.behoben?
Über jeden Lösungsvorschlag würde ich mich freuen.
Viele Grüße
Romuald
ich hätte da mal ein Problem......
Seit heute am Morgen (13.11.2019) erhalte ich die Fehlermeldung "Abfrage '' ist beschädigt" unter meiner Access 2013-Applikation. Bis gestern lief alles wunderbar und ich habe auch nichts verändert bzw.Installiert auf meinem Rechner. Das Office-Paket habe ich bereits "repariert", allerdings ohne Erfolg bei der Fehlermeldung.
Hat jemand so etwas schon mal gehabt bzw.behoben?
Über jeden Lösungsvorschlag würde ich mich freuen.
Viele Grüße
Romuald
Please also mark the comments that contributed to the solution of the article
Content-ID: 514571
Url: https://administrator.de/contentid/514571
Printed on: November 5, 2024 at 15:11 o'clock
17 Comments
Latest comment
Ja, ganz früher mal regelmäßig, ein Grund warum Access für dauerhaft zuverlässige Datenbanken ungeeignet ist. Es hält sich für ein Mitglied von Mission Impossible und zerstört sich immer wieder grundlos von selbst, es reicht die Datenbank nur aufzurufen und pro Aufruf wird sie erstens immer größer und zweitens ändert sie ihre Inhalt egal ob man darin etwas ändert oder nicht.
Mein dringender Tipp => Umsteigen!
Wenn das nicht in Frage kommt Access nur als Frontend für SQL Datenbackends nutzen, aber nicht die Daten in Access selbst speichern!
Mein dringender Tipp => Umsteigen!
Wenn das nicht in Frage kommt Access nur als Frontend für SQL Datenbackends nutzen, aber nicht die Daten in Access selbst speichern!
Also ich habe denselben Fehler.
Meine dahinterstehende Excel wird von mehreren Usern benutzt (ca. 40) aber nur ein User hat diesen Fehler.
Bei den anderen funktionieren die Abfragen einwandfrei.
Die Datenbank zu kopieren, hat leider nichts gebracht aber ich werde weiter herumprobieren.
Bei ihm war es ebenfalls so, dass der Fehler seit genau heute, den 13.11.2019, auftritt.
Gestern hat es einwandfrei funktioniert.
Ich hoffe, Microsoft bringt einen Patch.
Mfg
Meine dahinterstehende Excel wird von mehreren Usern benutzt (ca. 40) aber nur ein User hat diesen Fehler.
Bei den anderen funktionieren die Abfragen einwandfrei.
Die Datenbank zu kopieren, hat leider nichts gebracht aber ich werde weiter herumprobieren.
Bei ihm war es ebenfalls so, dass der Fehler seit genau heute, den 13.11.2019, auftritt.
Gestern hat es einwandfrei funktioniert.
Ich hoffe, Microsoft bringt einen Patch.
Mfg
Es sind wohl alle Office-Versionen von 2010 bis 2016 betroffen, auf denen das Sicherheitsupdate für die Schwachstelle CVE-2019-1402 installiert wurde. Dann klappt der Access-Zugriff nicht mehr. In nachfolgendem Beitrag sind die betroffenen Sicherheits-Updates für die einzelnen Office-Versionen aufgelistet.
Access Fehler 3340 durch November 2019-Updates
Ergänzung: Ich habe das Problem gerade per Chat an den US Support von Microsoft gemeldet.
Ergänzung 2: Es gibt jetzt einen Supporteintrag bei Microsoft, ein Fix ist unterwegs (kommt am 24. November für O365 und am 10. Dezember für den Rest) und es wird ein Workaround vorgeschlagen.
Access Fehler 3340 durch November 2019-Updates
Ergänzung: Ich habe das Problem gerade per Chat an den US Support von Microsoft gemeldet.
Ergänzung 2: Es gibt jetzt einen Supporteintrag bei Microsoft, ein Fix ist unterwegs (kommt am 24. November für O365 und am 10. Dezember für den Rest) und es wird ein Workaround vorgeschlagen.
Welcome to the MS-Alpha-Release-Testing-Group .
Hallo miteinander!
In meinem Betrieb nutzen wir sowohl Access2013, wie auch Access2016 und entwickeln Datenbanken mit Access als Aus- und Eingabeschnittstelle mit SQL als Datenbankmedium.
Wir haben ebenfalls bei allen Access 2013 Anwendungen Error 3340 bei jedem docmd.Runsql "Update ..." Aufruf!
Delete funktioniert problemlos mit Runsql.
Bei Access2016 lokal haben wir das Problem derzeit nicht.
Dieses Problem betrifft sowohl unsere Terminalserver-Ebenen mit Access 2013 UND 2016, wie auch alle lokalen Logins, die 2013 drauf haben.
In meinem Betrieb nutzen wir sowohl Access2013, wie auch Access2016 und entwickeln Datenbanken mit Access als Aus- und Eingabeschnittstelle mit SQL als Datenbankmedium.
Wir haben ebenfalls bei allen Access 2013 Anwendungen Error 3340 bei jedem docmd.Runsql "Update ..." Aufruf!
Delete funktioniert problemlos mit Runsql.
Bei Access2016 lokal haben wir das Problem derzeit nicht.
Dieses Problem betrifft sowohl unsere Terminalserver-Ebenen mit Access 2013 UND 2016, wie auch alle lokalen Logins, die 2013 drauf haben.
Für alle, die extern auf die Datenbank zugreifen und nicht mit dem von Microsoft präsentierten Workaround arbeiten können.
Hierzu muss auch das Update nicht deinstalliert werden, ist jedoch ein Aufwand zu ändern:
Ich schreibe nicht per SQL in die Tabelle, sondern öffne sie über DBO als RecordSet.
Mit RecordSet.Seek Edit und Update kann man schön die Tabelle bearbeiten.
Achtung das ist nur ein Hotfix und hat definitiv Optimierungsbedarf:
Man könnte natürlich anstelle .Seek auch durch die Fields loopen und so ändern aber jedem das Seine.
Mfg
Hierzu muss auch das Update nicht deinstalliert werden, ist jedoch ein Aufwand zu ändern:
Ich schreibe nicht per SQL in die Tabelle, sondern öffne sie über DBO als RecordSet.
Mit RecordSet.Seek Edit und Update kann man schön die Tabelle bearbeiten.
Achtung das ist nur ein Hotfix und hat definitiv Optimierungsbedarf:
Dim DataBaseChg As DAO.Database
Dim RecordSetChg As DAO.RecordSET
If MsgBox("Wollen Sie die Änderungen sicher speichern?" & vbCrLf & "Diese Aktion kann nicht rückgängig gemacht werden", vbYesNo, "Sichern") = vbYes Then
Set DataBaseChg = DAO.OpenDatabase("Pfad der Datenbank")
Set RecordSetChg = DataBaseChg.OpenRecordset("Tabellenname")
RecordSetChg.MoveFirst
RecordSetChg.Index = "PrimaryKey"
RecordSetChg.Seek "=", Val("ID") 'Suche nach der ID
If RecordSetChg.NoMatch Then
RecordSetChg.Close
DataBaseChg.Close
MsgBox "ID nicht gefunden", , "Fehler"
Exit Sub
Else
RecordSetChg.Edit
RecordSetChg("[Spaltenname]") = CStr("Neuer Wert")
End If
End If
RecordSetChg.Update
RecordSetChg.Close
DataBaseChg.Close
Man könnte natürlich anstelle .Seek auch durch die Fields loopen und so ändern aber jedem das Seine.
Mfg
Ich habe im Microsoft Forum den weiter unten folgenden Beitrag gepostet, der ein VBA-Skript enthält, dass automatisch den von Microsoft angegebenen Workaround (Umweg über Abfragen gehen) implementiert:
The CVE-2019-1402 updates (KB4484119, etc.) break Access 2010/2013/2016/365: Query '' is corrupt
Hier der Beitrag:
Use the following module to automatically implement Microsofts suggested workaround (using a query instead of a table). As a precaution, backup your database first.
Use AddWorkaroundForCorruptedQueryIssue() to add the workaround and RemoveWorkaroundForCorruptedQueryIssue() to remove it at any time.
You can find the latest code on my GitHub repository.
AddWorkaroundForCorruptedQueryIssue() will add the suffix "_Table" to all non-system tables, e.g. the table "IceCreams" would be renamed to "IceCreams_Table".
It will also create a new query with the original table name, that will select all columns of the renamed table. In our example, the query would be named "IceCreams" and would execute the SQL "select * from [IceCreams_Table]".
RemoveWorkaroundForCorruptedQueryIssue() does the reverse actions.
I tested this with all kinds of tables, including external non-MDB tables (like SQL Server). But be aware, that using a query instead of a table can lead to non-optimized queries being executed against a backend database in specific cases, especially if your original queries that used the tables are either of poor quality or very complex.
In my case I needed to manually rename [USysRibbons_Table] back to [USysRibbons], as I hadn't marked it as as system table.
The CVE-2019-1402 updates (KB4484119, etc.) break Access 2010/2013/2016/365: Query '' is corrupt
Hier der Beitrag:
Use the following module to automatically implement Microsofts suggested workaround (using a query instead of a table). As a precaution, backup your database first.
Use AddWorkaroundForCorruptedQueryIssue() to add the workaround and RemoveWorkaroundForCorruptedQueryIssue() to remove it at any time.
Option Compare Database
Option Explicit
Private Const WorkaroundTableSuffix As String = "_Table"
Public Sub AddWorkaroundForCorruptedQueryIssue()
On Error Resume Next
With CurrentDb
Dim tableDef As tableDef
For Each tableDef In .tableDefs
Dim isSystemTable As Boolean
isSystemTable = tableDef.Attributes And dbSystemObject
If Not EndsWith(tableDef.Name, WorkaroundTableSuffix) And Not isSystemTable Then
Dim originalTableName As String
originalTableName = tableDef.Name
tableDef.Name = tableDef.Name & WorkaroundTableSuffix
Call .CreateQueryDef(originalTableName, "select * from [" & tableDef.Name & "]")
Debug.Print "OldTableName/NewQueryName" & vbTab & "[" & originalTableName & "]" & vbTab & _
"NewTableName" & vbTab & "[" & tableDef.Name & "]"
End If
Next
End With
End Sub
Public Sub RemoveWorkaroundForCorruptedQueryIssue()
On Error Resume Next
With CurrentDb
Dim tableDef As tableDef
For Each tableDef In .tableDefs
Dim isSystemTable As Boolean
isSystemTable = tableDef.Attributes And dbSystemObject
If EndsWith(tableDef.Name, WorkaroundTableSuffix) And Not isSystemTable Then
Dim originalTableName As String
originalTableName = Left(tableDef.Name, Len(tableDef.Name) - Len(WorkaroundTableSuffix))
Dim workaroundTableName As String
workaroundTableName = tableDef.Name
Call .QueryDefs.Delete(originalTableName)
tableDef.Name = originalTableName
Debug.Print "OldTableName" & vbTab & "[" & workaroundTableName & "]" & vbTab & _
"NewTableName" & vbTab & "[" & tableDef.Name & "]" & vbTab & "(Query deleted)"
End If
Next
End With
End Sub
'From https://excelrevisited.blogspot.com/2012/06/endswith.html
Private Function EndsWith(str As String, ending As String) As Boolean
Dim endingLen As Integer
endingLen = Len(ending)
EndsWith = (Right(Trim(UCase(str)), endingLen) = UCase(ending))
End Function
You can find the latest code on my GitHub repository.
AddWorkaroundForCorruptedQueryIssue() will add the suffix "_Table" to all non-system tables, e.g. the table "IceCreams" would be renamed to "IceCreams_Table".
It will also create a new query with the original table name, that will select all columns of the renamed table. In our example, the query would be named "IceCreams" and would execute the SQL "select * from [IceCreams_Table]".
RemoveWorkaroundForCorruptedQueryIssue() does the reverse actions.
I tested this with all kinds of tables, including external non-MDB tables (like SQL Server). But be aware, that using a query instead of a table can lead to non-optimized queries being executed against a backend database in specific cases, especially if your original queries that used the tables are either of poor quality or very complex.
In my case I needed to manually rename [USysRibbons_Table] back to [USysRibbons], as I hadn't marked it as as system table.
Microsoft hat zum 18.11.2019 einen Hotfix (Update KB4484198) zur Korrektur des Fehlers in Access 2016 (MSI-Install) freigegeben. Auch für die anderen Access-Versionen sollen die Fixes deutlich früher als angekündigt (diese Woche) kommen. Details finden sich im Beitrag:
Fix für Fehler 3340 in Access 2016 (Update KB4484198)
Fix für Fehler 3340 in Access 2016 (Update KB4484198)