TerminalBasic/openspec/changes/archive/2026-09-05-isam-transaktionen-und-dateinummern/specs/isam-datenbank/spec.md

MODIFIED Requirements

Requirement: Datenbank- und Tabellenbindung an eine Dateinummer

OPEN datenbank$ FOR ISAM typname tabellenname AS #n SHALL eine Tabelle einer Datenbankdatei an eine Dateinummer binden. Das Satzlayout SHALL sich aus dem benannten benutzerdefinierten Typ ergeben; dessen Felder sind die Spalten der Tabelle. Existiert die Tabelle noch nicht, SHALL sie mit diesem Layout angelegt werden; existiert sie mit abweichendem Layout, MUST Laufzeitfehler 88 „ISAM - Database inconsistent" auftreten. Ein ungültiger Tabellen- oder Datenbankname MUST Fehler 81 „ISAM - Invalid name" auslösen. CLOSE SHALL die Bindung lösen; ausstehende Änderungen sind dabei bereits festgeschrieben, weil jede Operation außerhalb einer Transaktion für sich eine Transaktion ist. Eine laufende Transaktion MUST CLOSE unberührt lassen — über ihr Ende entscheiden allein COMMITTRANS und ROLLBACK ALL. DELETETABLE SHALL eine Tabelle samt ihren Indizes entfernen; eine nicht vorhandene Tabelle MUST Fehler 82 „ISAM - Table not found" auslösen.

Eine weitere Bindung derselben Datenbank innerhalb einer laufenden Transaktion SHALL deren bisherigen Zustand sehen und MUST ohne implizites Festschreiben oder Selbstblockade entstehen.

OPEN und DELETETABLE SHALL relative Datenbankpfade im aktuellen Arbeitsverzeichnis auflösen und kanonisch auflösbare Aliase derselben Datei gemeinsam verwalten. Bereits offene Bindungen MUST nach CHDIR weiterhin auf ihre ursprünglich geöffnete Datenbank zeigen. DELETETABLE SHALL bei Erfolg alle Bindungen der entfernten Tabelle lösen; weitere Zugriffe über diese Nummern MUST Fehler 52 melden. Eine Rücknahme SHALL die gelöschte Tabelle wiederherstellen, ohne geschlossene Bindungen erneut zu öffnen.

Scenario: Gleicher relativer Name nach Verzeichniswechsel

• WHEN nach OPEN in Verzeichnis A alle Bindungen geschlossen werden und derselbe relative Name in Verzeichnis B geöffnet wird
• THEN betreffen Lesen und Schreiben die Datei in B; die Datei in A bleibt unverändert

Scenario: Pfadalias in einer Transaktion

• WHEN dieselbe vorhandene Datenbank nach BEGINTRANS und INSERT über einen relativen oder absoluten Pfadalias erneut geöffnet wird
• THEN sieht die neue Bindung die bisherigen Änderungen ohne zweiten Writer; ROLLBACK ALL nimmt die Änderungen zurück

Scenario: Neuanlage über einen noch nicht auflösbaren Symlink

• WHEN OPEN eine Datenbank über einen Symlink mit bislang fehlender Zieldatei anlegt und die Datenbank danach innerhalb einer Transaktion erneut über Alias oder Zielpfad geöffnet wird
• THEN teilen alle Bindungen denselben Transaktionszustand; Sicherungspunkt-Rücknahme und ROLLBACK ALL funktionieren über beide Pfade

Scenario: Bindungen nach Tabellenlöschung und Rücknahme

• WHEN eine mehrfach gebundene Tabelle nach SAVEPOINT mit DELETETABLE gelöscht und anschließend zurückgenommen wird
• THEN sind die alten Bindungen geschlossen; ein erneutes OPEN sieht wieder die ursprünglichen Sätze und Indizes

Scenario: Tabelle wird beim ersten Öffnen angelegt

• WHEN eine Datenbank ohne die Tabelle Kunden mit OPEN "db" FOR ISAM KundeTyp "Kunden" AS #1 geöffnet wird
• THEN entsteht die Tabelle mit den Feldern des Typs und die Dateinummer ist nutzbar

Scenario: Abweichendes Satzlayout

• WHEN eine bestehende Tabelle mit einem Typ geöffnet wird, dessen Felder nicht zu ihren Spalten passen
• THEN tritt Laufzeitfehler 88 auf

Scenario: CLOSE lässt eine laufende Transaktion stehen

• WHEN innerhalb einer Transaktion eine andere Dateinummer mit CLOSE geschlossen wird
• THEN läuft die Transaktion weiter und ein folgendes ROLLBACK ALL nimmt ihre Änderungen zurück

Scenario: Entfernte Tabelle

• WHEN DELETETABLE für eine nicht vorhandene Tabelle aufgerufen wird
• THEN tritt Laufzeitfehler 82 auf

Scenario: Weitere Tabelle während einer Transaktion

• WHEN nach BEGINTRANS und INSERT eine zweite Tabelle derselben Datenbank geöffnet und danach ROLLBACK ALL ausgeführt wird
• THEN kehrt OPEN zurück; die eingefügten Daten sind nach Wiederöffnung nicht festgeschrieben

Requirement: Transaktionen mit Rücknahme

BEGINTRANS SHALL eine Transaktion eröffnen, COMMITTRANS alle Änderungen seit ihrem Beginn festschreiben und ROLLBACK sie zurücknehmen. SAVEPOINT SHALL als Funktion einen Sicherungspunkt setzen und dessen Kennung liefern; ROLLBACK mit einer solchen Kennung SHALL auf diesen Punkt zurücksetzen, ohne die Transaktion aufzugeben. ROLLBACK ALL SHALL alle Änderungen seit BEGINTRANS zurücknehmen und die Transaktion beenden. Nach jeder Rücknahme MUST der Satzbestand einschließlich aller Indizes dem Zustand zum Bezugspunkt entsprechen und der Cursor als unpositioniert gelten. Eine beim Programmende nicht festgeschriebene Transaktion MUST wirkungslos bleiben.

Die Rücknahme auf einen Sicherungspunkt SHALL auch seitdem angelegte oder gelöschte Indizes und Tabellenstrukturen einschließlich ihrer Metadaten zurücknehmen. CLOSE einer Bindung MUST die spätere Rücknahme ihrer Änderungen weiterhin erlauben.

Scenario: Rücknahme stellt den Bestand wieder her

• WHEN nach BEGINTRANS Sätze eingefügt und gelöscht werden und dann ROLLBACK folgt
• THEN entspricht der Bestand beim erneuten Durchlauf dem Zustand vor BEGINTRANS

Scenario: Rücknahme auf einen Sicherungspunkt

• WHEN innerhalb einer Transaktion s = SAVEPOINT ausgewertet, danach geändert und mit ROLLBACK s zurückgesetzt wird
• THEN bleiben die Änderungen vor dem Sicherungspunkt erhalten und die danach sind zurückgenommen

Scenario: ROLLBACK ALL beendet die Transaktion

• WHEN nach mehreren Sicherungspunkten ROLLBACK ALL ausgeführt wird
• THEN entspricht der Bestand dem Zustand vor BEGINTRANS und die Transaktion ist beendet

Scenario: Indexanlage nach Sicherungspunkt

• WHEN nach SAVEPOINT ein Index angelegt und auf den Sicherungspunkt zurückgesetzt wird
• THEN ist der neue Index nicht vorhanden; SETINDEX mit seinem Namen löst Fehler 83 aus

Scenario: Geschlossene Tabelle rücknehmen

• WHEN eine geänderte Tabellenbindung vor ROLLBACK auf einen Sicherungspunkt geschlossen wird
• THEN gelingt die Rücknahme und der bei Wiederöffnung sichtbare Satz-/Indexbestand entspricht dem Sicherungspunkt

Requirement: Pufferverwaltung mit benanntem Fehler

SETMEM SHALL als Funktion die für ISAM verfügbare Puffergröße um den übergebenen Betrag ändern und die danach verfügbare Größe liefern. Reicht der verfügbare Puffer für eine Operation nicht aus, MUST Laufzeitfehler 89 „ISAM - Insufficient ISAM buffers" auftreten statt eines generischen Fehlers oder eines stillen Abbruchs. Weicht die Bedeutung von SETMEM mangels DOS-Speichermodell vom Vorbild ab, MUST die Abweichung in docs/sprachreferenz.md dokumentiert sein.

DELETE SHALL den benötigten Satz-/Undo-Puffer vor der Änderung prüfen. Bei Fehler 89 MUST Satzbestand, Indexbestand und Cursor unverändert bleiben.

Scenario: Pufferfehler wird benannt

• WHEN eine Operation den verfügbaren ISAM-Puffer überschreitet
• THEN tritt Laufzeitfehler 89 auf

Scenario: DELETE bei ausgeschöpftem Puffer

• WHEN DELETE auf einem gültigen aktuellen Satz bei unzureichendem ISAM-Puffer ausgeführt wird
• THEN meldet es Fehler 89 ohne den Satz zu löschen, den Cursor zu verschieben oder Undo hinzuzufügen; eine spätere Rücknahme bleibt möglich