Wenn eine Datenbank plötzlich nicht mehr funktioniert, nachdem sie es jahrelang ohne Probleme tat, kann die Ursache ein übergelaufenes Faß sein. Es gibt kein schrankenlos liberales System, im Leben nicht und nicht in der Datenwelt. Hier wie dort sind die Grenzen nicht immer leicht zu erkennen, und die Auswirkungen einer Überschreitung können durchaus überraschend sein. Selten auf angenehme Weise, versteht sich, und Verwunderung bis Verärgerung macht sich breit, daß einen "das System" nicht rechtzeitig und unmißverständlich gewarnt oder deutlich sichtbare Grenzpfähle aufgestellt hat. In der Tat, man füllt dauernd Material in diverse Fässer, sieht aber nicht, ob eins davon im nächsten Moment überlaufen wird. Muß man nicht klare und rechtzeitige Warnungen von einem System fordern, von dem man sich in einiger Hinsicht abhängig macht? Nicht alles ist jedoch leicht vorhersehbar, was in der Praxis vorkommt, doch Katastrophen muß man nicht befürchten.
Für das allegro-System wurden nicht von vornherein feste Grenzen abgesteckt. Im Verlauf der Entwicklung ergaben sich immer neue Anforderungen, aber auch neue Sachzwänge, und damit auch Veränderungen. Wir haben es nicht mit einer kleinen Anzahl von Fässern zu tun, die feste Abmessungen hätten, sondern es gibt einen begrenzten Speicherraum, in den alle Fässer zusammen hineinpassen müssen. Wenn ein paar davon besonders groß sind, müssen andere zwangsläufig kleiner sein. Dieser begrenzte Raum sind die unseligen 640 K des DOS-Systems. Diese Barriere, vielleicht die schlimmste Fehleinschätzung der Computergeschichte, wurde von IBM mit dem Entwurf des ersten PC 1983 aufgerichtet. Nicht nur das aktuelle Programm muß in diesen Raum passen, auch die Daten und Teile des Betriebssystems. Das ganze ist eine Optimierungsaufgabe, die mit dem Anwachsen des Systems immer schwieriger wurde. Das ist der entscheidende Grund, warum die DOS-Version am Ende kaum noch funktional erweitert werden konnte. Die Windows-Version kann freier durchatmen, aber grenzenlose Freiheit kennt auch diese nicht.
Im Handbuch sind eine Reihe von Grenzwerten erwähnt. Sie stehen aber nirgends alle übersichtlich verzeichnet, und außerdem sind die Angaben teilweise überholt. Hier soll der aktuelle Stand dargestellt werden. Es können sich immer noch Veränderungen ergeben, jedoch werden diese selten dramatisch ausfallen. Für UNIX und Windows sind die entsprechenden Werte im allgemeinen gleich oder größer oder können nach oben erweitert werden. Nur bei DOS besteht das Problem, daß man nicht alle Werte zugleich auf ihr Maximum setzen kann - dafür ist besagter Raum zu klein. Bei UNIX und Windows gibt es diese Sorgen nicht. Man muß aber bedenken: solange eine Datenbank noch zugleich unter DOS wie UNIX oder Windows benutzbar sein soll, gelten leider an manchen Punkten die DOS-Grenzen.

ACHTUNG: Wer in die Nähe einer Grenze gerät, etwa mit extrem langen Datensätzen, muß wissen, daß nicht alles total abgesichert ist - das liegt einfach in der Natur der Dinge - und deshalb Fehlfunktionen bis hin zu Abstürzen ohne Fehlermeldung nicht ausgeschlossen sind.

Grenzen des Wachstums

Datenbank

Eine allegro-Datenbank könnte maximal 2³²-1=4.294.967.295 Sätze enthalten. Die größten Datenbanken liegen bisher bei 25 Millionen Sätze. Man muß nirgends etwas für die Größe der eigenen Datenbank einstellen.

Datendateien

Die Daten müssen auf bis zu 255 Dateien des Typs .cLD mit jeweils bis zu 16 Millionen Byte aufgeteilt werden. (Mit Option -z kann man einen kleineren Wert einstellen.) Die Programme passen auf, d.h. sie machen ein neues Faß auf (legen eine neue Datei an), wenn eins überzulaufen droht. Wenn die Frage "Dateinummer?" kommt (z.B. beim Kopierbefehl C in Presto), muß diese mit einer Zahl zwischen 1 und 255 beantwortet werden.
Ab Nov.1999 (siehe Verlautbarung 124) können die Datendateien ein mehrfaches der Größe von 16MB erreichen: dazu dient der neue "Aufbohr-Faktor" in den Index-Parametern: der Wert  ii=2 bedeutet z.B. daß jede Datendatei 32MB groß sein darf. Nach Änderung dieses Wertes muß man die Datenbank neu aufbauen lassen.

Index

Wegen der Variabilität kann hier keine maximale Anzahl von Einträgen errechnet werden. Bei der größten bekannten Datenbank lag die Anzahl der Indexeinträge oberhalb 180 Millionen, wobei noch keine Probleme auftraten. Als Datei kann der Index jedoch nicht größer als 2 GB werden. Normalanwender haben also kein Problem zu befürchten, es sei denn Platzmangel auf der Platte.
Reicht eine Platte nicht aus, um die gesamte Datenbank aufzunehmen, kann man die Indexdatei und die Kurztiteldatei auf eine andere Platte (ein anderes Dateisystem) legen. Dann muß beim Programmstart (PRESTO, UPDATE, ...) mit Option -yindexpfad der Pfad angegeben werden, z.B. -yh:\allegro\daten .

Ab V27.2 kann eine Datenbank mehr als eine Indexdatei haben: das MultiX-Konzept ermöglicht es mit recht geringem Aufwand. 

Jede Indexdatei hat bis zu 11 Register. Mit symbolischen Namen kann man bis zu 100 logische Register einrichten. (Bis V30: 50.)
Hat man mehr als eine Indexdatei, können die logischen Register in jeder davon liegen, aber mehr als insgesamt 100 gibt es nicht.

LOG-Datei

Im Prinzip ist diese nicht in der Größe begrenzt, das Problem stellt sich aber gar nicht: Sie sollte jedesmal gelöscht werden, wenn eine Gesamtsicherung gemacht wird, und sie soll nicht mit gesichert werden (weil ihr Inhalt ja in der Datenbank schon enthalten ist). Das CockPit bringt zwar die Meldung "Die LOG-Datei ist etwas groß geworden, machen Sie bald mal eine Sicherung", das ist aber nur eine Erinnerung, man muß nicht sofort etwas tun. In der CockPit-Vorgabendatei, normalerweise CP.OPT, kann man mit dem Befehl L einstellen, bei welcher Größe diese Erinnerung kommen soll. Je größer die LOG-Datei ist, umso länger würde eine Wiederherstellung im Katastrophenfall dauern.
Wenn eine Datenbank nicht so wichtig und das Computersystem 100% ausfallsicher ist, kann man die LOG-Aufzeichnung abstellen: man ergänzt die Option -L zu allen Aufrufen von PRESTO und UPDATE.

Grenzwerte im Arbeitsspeicher  (PRESTO und APAC)

In der nachfolgenden Liste sind diejenigen Werte, die der Anwender verändern kann, durch Fettdruck und orange gekennzeichnet. Dort steht der Befehl, den man in der CFG dazu benutzen muß (siehe Anh. A.1.3, m-Befehle unter "Speicher konfigurieren").

Aufnahmespeicher        (enthält den aktuellen Datensatz) FLEX: var ca

Maximalgröße in Byte: Dos-Programme: mK48000   // a99, acon:  mK250000

Aus internen Gründen muß der längste Datensatz zweimal hineingehen, und für Nachladungen u.a. muß Platz bleiben. D.h. die Grenze für einen einzelnen Datensatz liegt bei ca. 20000 Byte (DOS) bzw. ca. 120000 (Windows, UNIX)..

Maximale Anzahl Datenfelder des Satzes: mk2500 

Wenn z.B. kein Satz mehr als 100 Kategorien hat, ist mk250 ein sicherer Wert.

Hierarchische Sätze gelten hierbei mitsamt allen Untersätzen als ein Satz.

Datenfelder

Maximale Feldlänge: intern auf 16000 Byte festgelegt, nicht einstellbar. (DOS: 10000)

Kategoriesystem md

In der CFG kann man maximal 2000 verschiedene Datenfeldnummern deklarieren. Standard sind 800. Die Kategorienummern können 2, 3 oder 4 Zeichen breit sein. (Mehr wird nicht empfohlen.)

Abfrageliste

Eine ausdrückliche Grenze für den Umfang der Abfrageliste gibt es nicht. Sie wird allerdings im Aufnahmespeicher untergebracht. Der durch den Befehl mK definierte Platz für den aktuellen Datensatz muß deshalb evtl. vergrößert werden, wenn man eine sehr lange Abfrageliste hat. In a99 nicht mehr von Belang.

Hintergrundspeicher (= Reservespeicher) mB    FLEX: var cr

Für die Kopien der zuletzt belegten Kategorien und für die Nutzervariablen (#uxx-Kategorien) sind standardmäßig 12000 Byte belegt. Obergrenze: 32000
Die maximale Anzahl mb Felder im Hintergrundspeicher ist auf 200 voreingestellt.   
Hat man lange Sätze und/oder viele Anwendervariablen, setze man den Wert herauf.
Wenn durch einen Fehler in den oder Exportparametern eine #u-Variable fortwährend verlängert wird, kann dieser Speicher an die Grenze kommen. Mit #a im Editor kann man sehen, welche Variable das ist.

Phrasenspeicher mP    FLEX: var cp

Als Standard sind 4000 Byte vorgegeben. Wenn man kaum mit Phrasen arbeitet, sollte man trotzdem nicht weniger als 1000 einstellen, weil hier auch z.B. die Zwischenteile der Exportparameter abgelegt werden.
Die Windows-Programme addieren noch 10000 auf den gesetzten Wert, weil der Phrasenspeicher noch weitere interne Aufgaben hat. Maximal können 1200 Zeichenfolgen im Phrasenspeicher stehen.

Parameterspeicher mX

Automatische Vorgabe sind 40000 Byte. Hat man sehr umfangreiche Index- und Anzeigeparameter und zusätzlich eine große Export-Parameterdatei, muß man einen größeren Wert einsetzen. Das Maximum ist 64000. Der benötigte Platz ist immer kleiner als die Größe der Parameterdateien, denn z.B. die Kommentare werden nicht mit gerechnet, und auch sonst wird intern platzsparend gespeichert. In PRESTO müssen alle (bis zu 4) geladenen Parameterdateien in diesen Raum passen, in a99/alcarta hat jede einzelne Parameterdatei soviel Platz.

Ergebnismenge mr

Relevant nur für PRESTO und die davon abgeleiteten Programme. Standard ist 15000, Maximum 16000. Um eine Datenbank bei Arbeitsspeichermangel erst einmal zum Funktionieren zu bringen, setzt man immer zuerst diesen Wert herunter, z.B. drastisch auf mr100, das spart sofort 60K.
In a99/alcarta dürfen Erg.Mengen bis zu 256.000 Einträge groß werden, dafür muß man nichts einstellen.

Artikelliste

Die Liste der am Anfang von Titeln zu prüfenden Wörter (d-Zeilen in der CFG) kann maximal 360 Byte lang sein.

Stoppwortliste

Die Liste der aus dem Index auszublendenden Wörter darf 1023 Einträge umfassen und wird mit im Parameterspeicher untergebracht.

UIF-Texte

Hierfür sind 15000 Byte und 500 Zeilen fest eingestellt. So stark kann man die Texte in den UIF-Dateien kaum verlängern, daß diese Grenze erreicht würde. (Die alten DOS-Programme aLF und ORDER hatten höhere Grenzen)

Formulare    [nur Windows-Programme]

Bis zu 250 Formulare können in einer .FRM-Datei definiert sein. Unterbringung im Phrasenspeicher, deshalb Wert mP in der CFG hoch genug setzen!

FLEXe    [nur Windows-Programme und avanti!]

FLEX-Dateien dürfen bis zu 256000 Bytes groß sein, bei avanti 100000. Das ist schon eine Menge!
Die "interne Variable" (iV) darf bis zu 4MB lang werden. (Aber Vorsicht: Ist sie länger als 10.000 Byte, kann man sie nicht mehr mit dem Befehl  ins  in eine Kategorie oder Hintergrund-Variable kopieren! Nur $-Variablen gehen dann, die fassen bis 64000 Byte.) Es gibt seit einiger Zeit eine zus�tzliche interne Variable, die iV2, mit demselben Maximum; man belegt sie mit "ins $" und kopiert sie mit "var $" wieder in die normale iV.

Hilfetexte    [nur Windows-Programme, ab V28.8.2!]

RTF-Dateien und der Text einer Datenanzeige im Anzeigefeld dürfen bis zu 4 MB Bytes groß sein.

Dateinamen

Alle Dateinamen sind in den DOS-Programmen auf eine maximale Länge von 64 Byte eingestellt (einschließlich Pfadname). In den UNIX- und Windows-Programmen sind es 255. Leerzeichen in Datei- und Pfadnamen sind nicht erlaubt, Verzeichnisnamen dürfen keine Namenserweiterung haben. Empfohlen wird, die 8.3-Konventionen einzuhalten und konsequent nur Kleinbuchstaben zu verwenden, keine Umlaute oder Akzentbuchstaben. Den Datenbanknamen (Standard: cat) sollte man sogar auf 4 Zeichen begrenzen, ohne das Zeichen _. Diese Namen sind intern, d.h. der Endnutzer sieht sie nicht, daher sind kryptische Namen unkritisch!

Indexeinträge

Für den aktuellen Satz wird Platz gebraucht, um die Registereinträge zwischenzuspeichern. Maximal kann ein Datensatz in PRESTO und UPDATE 500 Schlüssel haben, die gesamte Länge der Schlüssel darf bis zu 10000 Byte betragen.

Für Windows gelten die Werte: 1000 Schlüssel, 32000 Byte je Satz.

Diese Werte sind ansonsten nicht einstellbar.  

Das Programm INDEX allerdings kann beliebig viele beliebig umfangreiche Einträge je Satz erzeugen: siehe Vb154a, 25.4.2002

Mit der wichtigste Eintrag kann der "Primärschlüssel" sein (Handbuch S. 158/159).  Wie der aussieht, ist Sache des Anwenders, hierfür ist aber zu empfehlen, nur die folgenden Zeichen zu verwenden:
0...9, A...Z, a...z,   + , - / ;   sowie  Spatium und Punkt.

Grenzen in Export-Parameterdateien

Länge der Schlüssel

Registereinträge können bis zu 250 Byte lang sein (hinzu kommen automatisch 4 Byte für die Satznummer). Als Standard ist der Wert 60 als maximale Schlüssellänge eingestellt, meistens setzt man in den Indexparametern il=72 . Dies bedeutet nicht, daß für jeden Schlüssel soviel Platz verbraucht wird! (Im Gegenteil, die Schlüssel werden sogar komprimiert gespeichert.)

Kurzzeilen

Die Einträge der Kurztiteldatei (.STL-Datei) haben eine feste Länge, die mit i0=.. in den Indexparametern gesetzt wird. Das Maximum ist 250 (bis 1999: 72). Soviele Zeichen werden dann je Datensatz in der STL-Datei belegt. (Hier findet keine Komprimierung statt!)

Kopfbefehle

Die Gesamtlänge der ak-Befehle ist je Parameterdatei auf 4000 Byte fest begrenzt. 

Hat man viele solche Befehle, sollte man versuchen, durch Zusammenfassung Platz zu sparen, z.B. ak=4..+M , statt für jede der Kategorien der Gruppe #4 einen eigenen Befehl zu schreiben.

Zwischenteile

Je Parameterdatei kann es bis zu 100 Zwischenteile (= Textkonstanten) geben, das ist fest eingestellt. Sie müssen mit 0 bis 99 numeriert werden. 

Ab 5.2.2003 (V23.2): 128 Zwischenteile, in den Windows-Programmen sogar 400.

Basisparameter

Für einige der Basisparameter (Kap. 10.2.1-5) gibt es fest eingestellte maximale Längen: Die Parameter ab, as, ae sind auf 80 Byte begrenzt, fa, fb, fs auf 50 Byte, di auf 180 und pb auf 20. Überschreitung eines dieser Werte kann, aber muß nicht, unvorhersehbare Wirkungen haben. Die meisten Fehler werden abgefangen.

Exportzeile

Der Parameter zl für die Zeilenbreite ist auf 130 Byte begrenzt. Wenn man zl=0 setzt, findet kein Zeilenumbruch statt! Dies wird in der Regel gemacht, wenn der Umbruch einem Textsystem überlassen werden soll, z.B. auch für .rtf- und .htm-Dateien.

Programmspezifische Grenzen

CockPit

Die Anzahl der "Eigenen Routinen" ist auf 160 begrenzt, aufgeteilt auf bis zu 16 R-Zeilen mit jeweils bis zu 10 nachfolgenden S-Zeilen (diese bilden die Untermenüs zu den R-Zeilen).

SRCH

Wenn SRCH mit der Meldung "not enough space" aussteigt, sollte man in der CFG den Wert mK verkleinern.

IMPORT

Ein Datensatz der einzulesenden Fremddaten kann bis zu 40000 Byte lang sein. Dieser Wert ist nicht einstellbar.
Achtung bei umfangreichen Konkordanzlisten: Diese werden mit im Parameterspeicher untergebracht. Hat man sehr lange Konkordanzlisten, setze man den Wert mX in der CFG bis maximal 64000 hinauf.

ASORT

ASORT kann Dateien fast beliebiger Größe sortieren. Es erstellt vorsortierte Zwischendateien mit bis zu 64K Größe, die dann anschließend gemischt werden. Die maximale Zahl solcher Zwischendateien ist 9999.
Für das Sortieren ist die maximale Satzgröße auf 32000 Byte fest eingestellt. Bei Projekten mit sehr großen Datenmengen wird man allerdings nicht die Sätze selbst sortieren, sondern kurze Sortiersätze, die nur den Ordnungsbegriff und die Satznummer oder den Primärschlüssel enthalten. Nach dem Sortieren wird man in einem SRCH-Durchlauf dann die eigentlichen Sätze zum Aufbereiten aus der Datenbank nachladen. So ist es z.B. in der QUEX-Methode der Listenproduktion gelöst.