[Allegro] & noch etwas für V34.1

[Anando Eger]

Hallo Herr Berger,

habe gerade noch einmal gelesen:

| In grenzen.htm  steht unter 'FLEXe':
| ... 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.)
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^

Sollte das bedeuten, dass $-Variablen einzeln 4 MB Daten fassen 
können?

Viele Grüße
Anando Eger


> Hallo Herr Berger,
> 
> Sie schrieben u.a.:
> > nanu? Vgl. die Einlesevorgaenge ueber die iV:
> > "ins" setzt durchaus eine Gruppe von Kategorien aus der iV in den
> > Datensatz und der cstring kn ist fuer die inverse Operation zustaendig,
> > d.h. er wandelt den aktuellen Satz in eine Zeichenkette in der iV um.
> > 
> > Saetze bis 64kB sind damit behandelbar, 
> 
> eben. laut www.allegro-c.de/grenzen.htm ist die
> max. Feldlänge: 10.000 Bytes
> 
> Um zu verhindern, dass eine $-Variable überläuft, müsste man immer 
> erst die Länge aller im Record vorkommenden Felder ermitteln.
> Um was soll dann im Überlauf-Fall getan werden?
> 
> > > Vorstellbar wäre es, analog zu update entsprechend Modusziffer x 
> > > vorzugehen. ...
> >...
> > Ich kann nicht folgen: Wollen Sie so tun, als kennten Sie den
> > Satz nicht, den Sie aus Ihrem Powerspeicher holen? 
> 
> Ich habe mit den sich ergebenden Möglichkeiten gespielt ...
> 
> Die Möglichkeit, dass ein Record in der DB zwischenzeitlich von 
> einer anderen Instanz geändert wurde, ist ja immerhin gegeben.
> 
> > klar. Aber diesmal bitte mit Namespace.
> :-)
> 
> Zu ixadd und Verwandte:
> 
> Dieser "z"-Index hat sicher einen Laufzeitvorteil gegenüber der 
> Speicherung von Konfigurationsdaten in einem speziellen 
> Konfigurations-Record.
> 
> Aber lohnt es sich, deswegen so eine (in meinen Augen: "krumme") 
> Speichermöglichkeit zu schaffen?
> 
> Ich weiß nicht ... Welcher Anwendungfall benötigt genau die 
> Speichereigenschaften, die ein Allegro-Datenbank-Indexeintrag  
> exclusiv bietet?
> 
> Viele Grüße
> Anando Eger
> 
> 
> 
> 
> > Lieber Herr Eger,
> > 
> > >> ... aber in der Eger'schen
> > >> < http://www.aneg-dv.de/allegro/modpar/files/mp_stack.flb >
> > >> hatte ich sehr wohl bemerkt, dass man auch ganze Datensaetze
> > >> in den Stack packen kann (nebst ihrer internen Satznummer).
> > > 
> > > PushRec/PopRec arbeiten nur mit der Satznummer als Referenz, d.h., 
> > > die Inhalte werden nicht gespeichert. 
> > > 
> > > Wollte man den Record-Inhalt in Variablen speichern, müsste pro 
> > > Kategorie eine Variable belegt werden.
> > 
> > nanu? Vgl. die Einlesevorgaenge ueber die iV:
> > "ins" setzt durchaus eine Gruppe von Kategorien aus der iV in den
> > Datensatz und der cstring kn ist fuer die inverse Operation zustaendig,
> > d.h. er wandelt den aktuellen Satz in eine Zeichenkette in der iV um.
> > 
> > Saetze bis 64kB sind damit behandelbar, erst beim einsetzen in
> > die Indexzeilen mit 252 Zeichen Laenge - Zugriffsschluesseln
> > wird es haarig, das kann aber auch bereits bei Einzelkategorien
> > der Fall sein.
> > 
> > 
> > > Vorstellbar wäre es, analog zu update entsprechend Modusziffer x 
> > > vorzugehen. Eine Herausforderung wäre dabei die Umsetzung der 
> > > Mehrfachfelder-Funktionen.
> > 
> > Ich kann nicht folgen: Wollen Sie so tun, als kennten Sie den
> > Satz nicht, den Sie aus Ihrem Powerspeicher holen? Oder denken
> > Sie an eine neue Art des Datentransports, indem .azx-Dateien
> > verteilt und die Zieldaten sich dann echt neue Daten saugen?
> > 
> > 
> > > Ein Retten dieses Stacks für eine Zeit nach dem Programmende halte 
> > > ich nicht für sinnvoll, denn dann hat man wieder das Problem mit der 
> > > Lebensdauer der Recordnummern - es sei denn, man nutzt anstatt der 
> > > Record-Nummern den Primärschlüssel als update-Kriterium.
> > 
> > klar. Aber diesmal bitte mit Namespace.
> > 
> > Ich denke ernsthaft an Anwendungsfaelle wie das, was bislang in
> > .ini-Dateien gespeichert ist (sie kranken wie die .cfg's daran,
> > das heiligste (Name der Indexparameter) mit dem Profanen
> > (Fensterposition) zu vermengen) oder die bislang nur rudimentaer
> > in order.inc oder alf.inc hinterlegten grundlegenden Anwendungs-
> > Parameter besser pflegbar zu machen. Im Zusammenhang mit ixadd
> > und ixdel war auch eine Moeglichkeit beschrieben worden, ganze
> > Indexbereiche pauschal zu exportieren und wieder einzulesen,
> > das wird man dann brauchen.
> > 
> > 
> > viele Gruesse
> > Thomas Berger
> > 
> > _______________________________________________
> > Allegro mailing list
> > Allegro at biblio.tu-bs.de
> > http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro
> 
> 
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro