Access-o-Mania

Moin zusammen,

ich hab ein (für mich wenigstens) sehr diffuses Problem, mit dem ich nicht weiterkomme, und bin auf Suche nach Hilfe bzw. Ideen, was man tun könnte: Habe in einem 200MB großen Backend (aktuelle MS 365 Version) mit zahlreichen Tabellen eine Tabelle, wo ich ein Textfeld von Größe=3 Zeichen auf Größe=5 Zeichen ändern wollte. Abbruch mit Fehlermeldung "nicht genügend Speicherplatz oder Arbeitsspeicher".

Nach Netz-Recherche als Erstes die üblichen Hausmittel probiert:
- Backend in eine neue, leere Datei importieren. Geht fehlerfrei, egal ob ganzes Backend oder nur "Problem-Tabelle", Problem bleibt bestehen.
- Feld-Inhalte per PlainText-Update bereinigt. Problem bleibt bestehen.
- andere / final dann allen anderen Textfelder in gleicher Tabelle per PlainText-Update bereinigt. Problem bleibt bestehen.
- Prüfung der anderen Textfelder (Größe=255 Zeichen, Inhalte weit unter der Grenze); dennoch Änderung in Memo,
- ich weiss nicht, was ich noch alles probiert hab, ich sitz seit 2 Wochen immer mal wieder dran.

Auch wenn das Netz incl. der offiziellen MS Doku spricht, es gäbe keine Größenbeschränkungen pro Tabelle, sondern nur pro Backend-Datei - und von den 2GB bin ich meilenweit weg - hab ich mal löschen getestet, zuerst eigentlich, weil ich potentiellen Datensalat in den Feldern, der sich durch die Plaintext-Konvertierung evtl nicht beheben lässt, ausschließen wollte. Ich hab also ...

- zuerst die ältesten Datensätze gelöscht,
- dann die neuesten Datensätze,
- dann per Zufallsfunktion irgendwelche, und das mehrfach wiederholt, damit Zufall wirklich Zufall bleibt,

... und wann immer ich mich einer bestimmten Anzahl von Datensätzen annähere, verschwindet das Problem. Die Tabelle hat unverändert ca. 354k Datensätze, bei Reduzierung auf ca. 315k kann ich mein "Problem-Feld" ändern.

Heute hab ich nun unter Beibehaltung aller Datensätze mal andere, nicht von dem eigentlichen Änderungsproblem betroffene Textfelder in gleicher Tabelle gelöscht. Schrittweise. Auch hier: Ab einer bestimmten Anzahl von gelöschten Feldern kann ich das Problem-Feld wieder ändern. Unterschiedliche Kombinationen von Lösch-Feldern ausprobiert.

Kann sich irgendjemand einen Reim hierauf machen, und mich in eine Richtung schubsen?

Verzweifelte Grüße!
Andre.

(Edit:Typos)

Hallo,

2 GB betrifft nur die Maximalgröße der Datenbankdatei als ganzes.
Tabellen haben aber eine maximale Datensatzgröße, bei SQL Server ist es 8KB, bei Access je nach Version 2000-4000 Zeichen. Ich würde also mal überprüfen, wieviele Felder Deine Tabelle hat und wie groß diese jeweils sind und ggf. an anderer Stelle kürzen.

Hier sind Spezifikationen zusammengefaßt:
https://ilias.uni-giessen.de/ilias.php?baseClass=ilrepositorygui&cmdNode=10e:p0:fk&cmdClass=ilInfoScreenGUI&cmd=showSummary&ref_id=399028

Man sieht leider oft, daß Tabellen vollgepropft sind mit Feldern über Feldern, wo so mancher die 255-Felder-Grenze schon erreicht. I.d.R. ist es mangelhafte Normalisierung. Für gewöhnlich braucht man im Durchschnitt nicht mehr als etwa 30 Felder pro Tabelle, danach wird es Zeit zum Auslagern/Umorganisation.

Im Notfall kann man auch vertikal teilen durch Verwendung einer 1:1-Beziehung, die sind aber nicht ganz einfach zu handhaben.


Viele Grüße

Christian

Hallo Christian,

danke für die schnelle Rückmeldung, und die Info. Diese "2000-4000" Zeichen pro Datensatz sind mir völlig neu, das kann / muss ich prüfen.

Ich hab derzeit 29 Felder in der Tabelle. 12 Textfelder, davon 9 mit 255 Zeichen, die anderen <10 Zeichnen.
Da wäre der Bereich "2000" Zeichen ja durchaus realistisch.

Ist ein Packende!
Ich melde mich zurück.

Andre.

Hallo,

Zitat12 Textfelder, davon 9 mit 255 Zeichen,

Was da eingestellt ist, spielt keine Rolle, Access reserviert keinen Speicherplatz. Auch wenn alle Felder auf 255 stehen, wird nur gespeichert was im Feld wirklich steht.
Und noch zusätzlich je 10 Bytes (?) für die Verwaltung des Feldes.

Hi zusammen,

versteh ich die Doku falsch? "Anzahl von Zeichen in einem Datensatz (wobei Memo-Felder und OLE-Objekte ausgeschlossen sind), wenn die UnicodeKompressions-Eigenschaft der Felder auf Ja gesetzt ist = 4000".

Ich hab jetzt alle Textfelder mit vorkommenden Inhalten > 20 Zeichen in der Tabelle ersetzt
- durch Anlegen "NameTextfeld_NEU", "Langer Text" mit Unicode-Kompression="Ja",
- Übertrag der Inhalte durch "UPDATE [NameTextfeld_NEU]=Plaintext(NameTextfeld) WHERE [NameTextfeld] not null",
- dann löschen des alten Feldes "NameTextfeld" und Umbenennen des neuen Felds "NameTextfeld_NEU" zu "NameTextfeld".

Dann sollten doch diese Felder bei der Zählung gegen 4000 Zeichen (und die 4000 erreich ich tatsächlich auch vorher nie, wenn ich nicht irgendwas noch nicht verstehe; 2000 hätte ich noch in Einzelfällen für realistisch gehalten) keine Rolle mehr spielen.

Der Rest der Tabelle besteht aus überwiegend Zahlen- und Datumsfeldern, zwei verbleibende Kurz-Text-Felder, UnicodeKompression dort auch Ja.

Das Problem besteht aber weiterhin.

Wenn du mal eine Beispiel-DB, bei der man das Problem nachstellen kann, hier hochladen könntest, wäre das eventuell hilfreich, schließlich kennt niemand hier die Tabellen noch die Daten, mit denen das Problem besteht.

Wenn sich das jemand ansehen mag, natürlich sehr gerne, aber ich würd dann lieber einen Link per PM senden.

Zum Einen sind's Kunden-Daten, und zum zweiten hat das Backend nach Abspecken auf die eine betrachtete Tabelle noch immer 70MB.

Datensätze reduziert, DB komprimiert und gezippt?

Hallo,

ich würde auch keine Kundendaten per PM schicken...
Besser ist: Du erstellt eine Kopie der problematischen Tabelle, dabei kannst Du sagen, ob Du nur das Schema kopieren willst, dann ist die kopierte Tabelle leer.
Die kannst Du in eine neue Datenbank importieren.
Hier kannst Du dann als erstes mal testen, ob Du hier die Anzahl Zeichen im Datensatz erweitern kannst, dann siehst Du, ob es ein Problem mit Deiner DB-Datei ist oder mit dem Tabellenschema.

Personenbezogene Daten solltest Du niemals weitergeben.

Gruß

Christian

Zitat von: Andre.Heisig am November 17, 2025, 10:43:50(aktuelle MS 365 Version) 

Bei Fehlern wie diesem, die auf ein Problem mit Access selbst zurückzuführen sein könnten, wäre es gut die genaue Version inkl. Build# und Bitness anzugeben.

Zitat von: Andre.Heisig am November 17, 2025, 10:43:50Abbruch mit Fehlermeldung "nicht genügend Speicherplatz oder Arbeitsspeicher".

Hast du die Nutzung des Arbeitsspeichers mal mit einem geeignetem Tool beobachtet? Evtl. wird hier durch eine ungünstige Konstellation von irgendwas internem tatsächlich das 4GB Limit erreicht.

Zitat von: Andre.Heisig am November 17, 2025, 10:43:50Auch wenn das Netz incl. der offiziellen MS Doku spricht, es gäbe keine Größenbeschränkungen pro Tabelle, sondern nur pro Backend-Datei

Es gab ein Limit von 1GB pro Tablespace und damit indirekt pro Tabelle. - Davon ist aber in der aktuellen Spezifikation nichts mehr zu lesen, und die Beschreibung des 2GB Dateilimits sagt implizit, dass dieses alte 1GB Limit nicht mehr besteht.
- Es wäre so oder so keine Grenze, die hier relevant sein dürfte.


Ich möchte als Workaround noch folgendes Vorschlagen:

• Erstelle eine neue Tabelle mit der gewünschten zukünftigen Struktur.
• Kopiere die Daten mittels Anfügeabfrage in die neue Tabelle
• Erstelle alle Fremdschlüssel-Beziehungen zu der neuen Tabelle
• Lösche die alten Fremdschlüssel-Beziehungen und die alte Tabelle.

Zitat von: PhilS am November 17, 2025, 14:55:52Ich möchte als Workaround noch folgendes Vorschlagen:

• Erstelle eine neue Tabelle mit der gewünschten zukünftigen Struktur.
• Kopiere die Daten mittels Anfügeabfrage in die neue Tabelle
• Erstelle alle Fremdschlüssel-Beziehungen zu der neuen Tabelle
• Lösche die alten Fremdschlüssel-Beziehungen und die alte Tabelle.

Hi Phil, auch Dir Danke fürs Teilnehmen,

ist das technisch unterschiedlich zu einer Tabellen-Erstellungs-Abfrage "Select * INTO [TabelleNeu] From [TabelleAlt]" ?
Das hab ich nämlich schon probiert.

Zitat von: Bitsqueezer am November 17, 2025, 14:53:03Besser ist: Du erstellt eine Kopie der problematischen Tabelle, dabei kannst Du sagen, ob Du nur das Schema kopieren willst, dann ist die kopierte Tabelle leer.
Die kannst Du in eine neue Datenbank importieren.
Hier kannst Du dann als erstes mal testen, ob Du hier die Anzahl Zeichen im Datensatz erweitern kannst, dann siehst Du, ob es ein Problem mit Deiner DB-Datei ist oder mit dem Tabellenschema.

Personenbezogene Daten solltest Du niemals weitergeben.

Die Daten selber sind produkt-bezogen, nicht personenbezogen, aber dennoch würd ich die ungern offen ins Netz stellen.

Ergebnis:
 - Tabelle kopieren "nur Struktur": ok
 - Feld ändern in neuer Tabelle: ok
 - Inhalte per Anfügeabfrage einfügen: ok
 - alte Tabelle löschen, neue umbenennen auf alten Namen: ok
 - Feld ändern in neuer Tabelle: gleicher Fehler wieder (auch wenn ich das Feld verkleinern wollte!)

Das klingt doch nach einem Daten-Mengen-Problem, oder nicht?

Zitat von: Andre.Heisig am November 17, 2025, 14:59:27ist das technisch unterschiedlich zu einer Tabellen-Erstellungs-Abfrage "Select * INTO [TabelleNeu] From [TabelleAlt]" ?

Ja, schon.  "Select * INTO [TabelleNeu] From [TabelleAlt]" übernimmt die alte Struktur (Felddefinitionen), die du ja ändern möchtest.

Hallo,

ja, das klingt danach, daß es genug Platz im Datensatz gibt, aber wenn Access die vorhandenen Daten anpassen will an die neuen Gegebenheiten, braucht es halt genug Speicher, um das durchführen zu können. Im ungünstigsten Fall die doppelte Menge, weil Quelle und Ziel.
Das hängt davon ab, welches Feld Du änderst. Wenn es am Ende der Liste ist, braucht Access keinen Platz dazwischen einzuräumen. Da in Access Datensätze keine feste Länge haben (wie in den meisten modernen Datenbanken), sondern abhängig vom Inhalt aller Felder, muß das pro Datensatz erledigt werden.
Was genau Access dabei intern macht - keine Ahnung. Sicherlich wäre ein einfacher Weg, die Daten in eine Temp-Datenbank zu kopieren, die alte Tabelle zu löschen, Strukturänderungen zu übernehmen, die Daten aus der Temp-DB wieder zu importieren und die Temp-DB zu löschen. Aber Access versucht halt immer, alles in der eigenen Datei zu machen.
Und wenn bei solchen Operationen der Systemspeicher nicht ausreicht, knallt es.

Also: Im Zweifelsfall selbst machen. Du hast ja bereits eine Methode festgestellt, was leider nicht so komfortabel ist, aber immerhin funktioniert.

Gruß

Christian

Das zu ändernde Feld ist das vierte von den 29, das entspricht deinen Erklärungen.

Aber ... meint Systemspeicher hier wirklich den RAM des Rechners, auf dem die Änderungen durchgeführt werden?
Ich sitze an einm PC mit 32GB, und ich seh die Speicherauslastung kaum springen, wenn ich in der Tabelle arbeite.

Zum "beheben" über den Export: Wäre nicht schön, aber machbar, diese Feldänderungen sind ja kein Tagesgeschehen. Mir macht das diffuse Platzproblem aber mehr Sorgen im Hinblick auf die Frage, wann knallt es an der Benutzer-Seite, sprich: Wann sind evtl. keine Daten mehr erfassbar oder änderbar, oder gehen inhaltlich kaputt.

Die Datenbank ist systemkritisch.

Hallo,

nein, das hat nichts mit dem RAM zu tun, abgesehen davon, daß Access ohnehin nicht das volle RAM verwenden kann, ist der Systemspeicher nochmal kleiner.

Hier ist vielleicht eine mögliche Erklärung und was man tun kann:
https://learn.microsoft.com/de-de/office/troubleshoot/access/error-when-perform-operation-on-table

Grundsätzlich kann ich nur empfehlen: Verabschiede Dich so bald wie möglich von Access als Backend. Das ist als Datenbank insbesondere in Geschäftsumfeldern und besonders beim Wort "systemkritisch" absolut unbrauchbar.

Als Backend sollte im Geschäftsfeld immer eine solide Datenbank her, SQL Server bietet sich hier an, weil es auch am besten mit Access zusammenarbeitet.

Es gibt mit SSMA ein kostenloses Migrationstool. Mit SQL Server Express kann man auch eine kostenlose Version verwenden, die allemal mehr drauf hat als Access.


Gruß

Christian

Ja, die Migration nach SQL hatten wir schon mal angesprochen, dann aber erstmal verworfen.
Werd ich wohl nochmal auf den Tisch bringen.

Hallo,

wie Christian das schon beschrieben hat, hat das nichts mit dem installierten Hauptspeicher zu tun, sondern mit dem freien virtuellen Speicher. Den kannst du relativ einfach mit dem Tool VMMap von Sysinternals für jeden Prozess ermitteln.

Eventuell ist auch die Einstellung ,,MaxLocksPerFile" (siehe Link) relevant. Es wäre zumindest einfach zu überprüfen, ob es hilft, diesen Wert zu vergrößern.

Zuallererst: Danke an alle fürs Brainstormen.

Ich fass mal zusammen:
 - Ich hab ein Mengenproblem, und die Empfehlung, auf SQL umzusteigen. Das bereite ich jetzt vor.
 - Ich hab einen Workaround, falls ich Änderungen an der Tabelle vornehmen muss. Ist nicht schön, aber möglich.

(Das nächste bitte nicht falsch verstehen @Bitsqueezer:)

Frage an @Knobbi38 und @PhilS: Teilt ihr Christian's (wir hatten einen längeren Austausch per PM) Einschätzung, dass die Betriebsstabilität des Access-Backends nicht unmittelbar gefährdet ist? Ich werd beim Kunden die Umstellung auf SQL dringend empfehlen, brauche mal ein Gefühl, wieviel Dampf ich auf den Kessel legen sollte.

Andre.

Zitat von: Andre.Heisig am November 19, 2025, 11:13:27Frage an @Knobbi38 und @PhilS: Teilt ihr Christian's (wir hatten einen längeren Austausch per PM) Einschätzung, dass die Betriebsstabilität des Access-Backends nicht unmittelbar gefährdet ist?

Ja, absolut.
Aus meiner Sicht ist die Fehlersituation sehr spezifisch durch Strukturänderungen an der Tabelle ausgelöst. Im normalen Betrieb könnte es schlimmstenfalls bei der Aktualisierung einer ähnlich großen Datenmenge (alle Datensätze der Tabelle) zu einer ähnlichen Fehlersituation kommen.
 

Ich schließe mich auch der Meinung an, dass kritische Anwendungen ein echtes DBMS als Backend haben sollten.

Dem Beitrag von Phil (#19) kann ich voll zustimmen - ich sehe das genauso.

Knobbi38

Hallo,

da gibt es schon aus einem einfachen Grund nicht viel zu überlegen: Wenn mein Geschäft von so einer DB abhängig ist, nicht jeder darauf zugreifen können soll oder sie kopieren, wenn ich sichere automatisierte Backups brauche, die z.B. auch Teilsicherungen sein können, wenn ich nicht mal einen Tag an Daten verlieren kann, weil ich wegen einer beschädigten Access-Datei zu einem alten Stand zurückgehen muß - sollte es nicht viel zu überlegen geben.

Zumal, wie gesagt, SQL Server mit Express ja auch einen kostenlosen Einstieg ermöglicht. Der ist natürlich beschränkt in dem, was er kann, aber das ist immer noch eine Menge mehr als Access bietet. Und Upscaling ist ja jederzeit möglich.

Gruß

Christian

Moin nochmal an alle,

ich hab gestern ein klares Nein vom Kunden bekommen zur Anfrage, ob ich eine abgespeckte Datenbank überhaupt mal hochladen dürfte.

Ich stell das Thema dann hiermit ein. Ich hab einen Workaround, es scheint keine akute Gefahr für die Datenbank zu existieren, und ich versuche jetzt, "dort" die Migration zu SQL voranzutreiben.


Nochmal vielen Dank an alle fürs Mitdenken, der Input war extrem hilfreich und wichtig.

Schöne Restwoche sei gewünscht!
Andre.