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

[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