Daten(mengen)-Problem in Tabelle ?!

Andre.Heisig · November 17, 2025, 10:43:50

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)

Bitsqueezer · November 17, 2025, 10:59:44

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

Andre.Heisig · November 17, 2025, 11:19:49

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.

MzKlMu · November 17, 2025, 12:06:19

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.

Andre.Heisig · November 17, 2025, 12:53:03

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.

Knobbi38 · November 17, 2025, 13:02:27

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.

Andre.Heisig · November 17, 2025, 13:26:12

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.

Knobbi38 · November 17, 2025, 14:28:06

Datensätze reduziert, DB komprimiert und gezippt?

Bitsqueezer · November 17, 2025, 14:53:03

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

PhilS · November 17, 2025, 14:55:52

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.

Andre.Heisig · November 17, 2025, 14:59:27

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.

Andre.Heisig · November 17, 2025, 15:01:08

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?

PhilS · November 17, 2025, 15:01:35

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.

Bitsqueezer · November 17, 2025, 18:09:21

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

Andre.Heisig · November 18, 2025, 09:11:15

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.

Neuigkeiten:

Daten(mengen)-Problem in Tabelle ?!