[Allegro] a99: erase offline nach set rec lock\put unlock

Mo Jan 24 16:37:15 CET 2011

Hallo Herr Eversberg,

ich war nicht genau genug beim Testen: 
'put' und 'put unlock' scheinen sich hinsichtlich des
'erase offline'-Problems nicht zu unterscheiden.

Dabei ist mir aber noch aufgefallen: Warum lädt
'erase offline' in folgender Situation NICHT den Satz #1?

x new 0\#00 0\put\erase\erase off\dis

Irgendwie verstehe ich die diesbezügliche Systematik nicht...

Viele Grüße
Anando Eger

---------------------------------------------------------------------
Anando Eger Datenverarbeitung
Herr Dipl.-Ing. Anando Eger
Gustav-Voigt-Str. 24
01156 Dresden
Tel.: +49 (0)351 454 1236  http://www.aneg-dv.de
Fax: +49 (0)351 454 1238  mailto:a.eger at aneg-dv.de
---------------------------------------------------------------------

On 24 Jan 2011 at 16:05, Anando Eger wrote:

> Hallo Herr Eversberg,
> 
> sie schrieben u.a.:
> 
> > Das "set rec lock" tut nichts zur und ändert nichts an der Sache.
> 
> Warum gibt es kein Problem, wenn der Satz vorher nicht 
> gelockt war und nur 'put' statt 'put unlock' benutzt wurde?
> 
> > Durch das "put" gelangt der Satz zusätzlich in den Reservespeicher.
> > Beseitigt man diesen mit "erase off" - 
> 
> 'erase off' löscht den Reservespeicher??? In xerase.rtf steht:
> +-----------------------------------------------------------------
> | erase off 
> | Der  Offline-Speicher  wird geleert. Anschließend kann man mit   
> | read file  eine neue Datei vom Typ .ALG oder .ADT in den 
> | Offline-Speicher laden. Sonst wird sie zusätzlich hinten 
> | angehängt an den Offline-Speicher. 
> +-----------------------------------------------------------------
> Ich benutze den Befehl, um die "Daten in Bearbeitung" zu eliminieren.
> 
> > was soll dann das Programm
> > machen? Wenn dieser Befehl kommt, dann prüft es nicht, ob der aktuelle
> > Satz einer ist, der durch "erase off" verschwände oder nicht. 
> 
> Warum eigentlich nicht?
> 
> > Daher
> > lädt es standardmäßig den Satz 1, den gibt es immer, und es kann nichts
> > schiefgehen, 
> 
> Und wenn das zufällig ein gelöschter Satz ist?
> 
> > falls der noch in der Anzeige stehende Satz aus irgendeinem
> > Grunde gar nicht erwünscht ist, weil er eben (in der angezeigten Form)
> > nur im Offline-Speicher stand, nun aber nicht mehr steht. (Und wer
> > weiß, was geschähe, wollte man damit nun irgendetwas tun.)
> > 
> > Abhilfe, wenn hernach derselbe Satz zu sehen sein soll wie zuvor:
> > Vorher die interne Satznummer sichern:
> > 
> > var i
> > ins $i
> > 
> > und am Ende, also nach "erase off", den Satz restaurieren bzw. Satz 1
> > nehmen, wenn der aktuelle zum Zeitpunkt der Ausführung ein offline-Satz
> > war (der ja dann weg ist):
> 
> Da in den Anwendungen, die ich per Flex realisiert habe, das 'erase off'
> als Workaround zur Beseitigung anderer Effekte (wie z.B. unmotiviertes
> Löschen von Sätzen aus der Datenbank beim Speichern (!!!) nach 
> 'set obj'-Befehlen) dient, hätte ich dann die Situation des 'Workarounds 
> eines Workarounds'. Lustig. Aber eigentlich auch nicht.
> 
> Was gebraucht wird ist eine Methode, wie man entweder die
> komplette Mechanik der "Daten in Bearbeitung" ausschalten oder
> zumindest diese Daten rück- und nebenwirkungsfrei entfernen kann.
> 
> Das Vorhalten des ursprünglichen Satzinhaltes bis zum Zeitpunkt,
> zu dem ich den Satz verwerfen oder speichern will, halte ich für
> nützlich. Aber: Dieser Zeitpunkt ist durch das Ende eines Editier- oder 
> sonstigen Veränderungsvorganges definiert.
> 
> Zwischenzeitlich muß der Datensatz verriegelt sein (ich gehe immer 
> vom Netzwerkbetrieb aus), da die Konflikterkennung über den nur 
> sekundengenauen definitiv zu unzuverlässig ist (-> schnelle 
> Infrastruktur, Zeitabweichungen auf den PC).
> 
> Das Verriegeln mehrerer Datensätze gleichzeitig traue ich mir 
> schon garnicht zu wünschen ;-)
> 
> Ich hoffe, Sie sehen, in welchem Kontext sich das Problem 
> bewegt.
> 
> Zu Ihrer Frage
> 
> > was soll dann das Programm machen?
> 
> 'erase offline' sollte "aufräumen":
> 
> Obligatorisch:
> - alle Offline-Sätze entfernen
> - alle temporär gespeicherten Datensatzinhalte "vernichten"
> - "Wechseln", "Aktivieren" bzw. 'undo' sind danach nicht mehr
>   möglich
> Fakultativ:
> - falls die aktuelle Anzeige den Inhalt eines gelöschten Satzes
>   zeigte, könnte sie geleert werden (== leerer Satz, evtl
>   mit Status neu?)
> - ein veränderter Satz in der Anzeige könnte wieder auf den
>   datenbanksynchronen Zustand zurückgestellt werden
> 
> Aber mir würde es schon genügen, wenn das 'erase off'
> nach 'put unlock' genau so funktioniert wie nach einem einfachen
> 'put'.
> 
> Irgendwas testet 'erase offline' doch, sonst würde doch immer 
> Satz 1 geladen und nicht nur, wenn sich ein gelöschter Satz 
> im Offline-Speicher befindet.
> 
> Läßt sich da nicht doch etwas machen? 
> 
> Viele Grüße
> Anando Eger
> 
> ---------------------------------------------------------------------
> Anando Eger Datenverarbeitung
> Herr Dipl.-Ing. Anando Eger
> Gustav-Voigt-Str. 24
> 01156 Dresden
> Tel.: +49 (0)351 454 1236  http://www.aneg-dv.de
> Fax: +49 (0)351 454 1238  mailto:a.eger at aneg-dv.de
> ---------------------------------------------------------------------
> 
> 
> 
> 
> On 24 Jan 2011 at 14:39, Bernhard Eversberg wrote:
> 
> > Am 24.01.2011 13:57, schrieb Anando Eger:
> > >
> > > schon lange bin ich auf der Jagd nach einem Fehler,
> > > durch den scheinbar unmotiviert Satz 1 der Datenbank
> > > angezeigt wird.
> > >
> > > Nun hab' ich ihn!
> > >
> > > Wird ein Satz gelöscht, danach ein anderer verriegelt und wieder
> > > mit "put unlock" freigegeben, "verstellt" ein folgendes
> > > 'erase offline' offensichtlich den internen Satzspeicher +
> > > zugehörige Variablen.
> > >
> > > Nachvollziehbar mit diesem Einzeiler
> > >
> > > x new 0\#00 0\put\erase\f1nd |9 sed\set rec l\put u\erase off\dis
> > >
> > > mit dem aktuellen a99 in der Demo-Datenbank (Der Satz mit der
> > > '#00 sed' sollte vorher vorhanden sein)
> > >
> > > Nach der Ausführung obiger Befehlsfolge erscheint Satz 1 der
> > > Datenbank anstatt des SED-Körperschaftsstammsatzes.
> > >
> > > Lasse ich 'set rec l\put u' weg, funktioniert alles scheinbar
> > > normal.
> > >
> > Es handelt sich nicht um einen Fehler, sondern ein Sicherheitsfeature.
> > Die Situation ist doch so:
> > 
> > Das "set rec lock" tut nichts zur und ändert nichts an der Sache.
> > Durch das "put" gelangt der Satz zusätzlich in den Reservespeicher.
> > Beseitigt man diesen mit "erase off" - was soll dann das Programm
> > machen? Wenn dieser Befehl kommt, dann prüft es nicht, ob der aktuelle
> > Satz einer ist, der durch "erase off" verschwände oder nicht. Daher
> > lädt es standardmäßig den Satz 1, den gibt es immer, und es kann nichts
> > schiefgehen, falls der noch in der Anzeige stehende Satz aus irgendeinem
> > Grunde gar nicht erwünscht ist, weil er eben (in der angezeigten Form)
> > nur im Offline-Speicher stand, nun aber nicht mehr steht. (Und wer
> > weiß, was geschähe, wollte man damit nun irgendetwas tun.)
> > 
> > Abhilfe, wenn hernach derselbe Satz zu sehen sein soll wie zuvor:
> > Vorher die interne Satznummer sichern:
> > 
> > var i
> > ins $i
> > 
> > und am Ende, also nach "erase off", den Satz restaurieren bzw. Satz 1
> > nehmen, wenn der aktuelle zum Zeitpunkt der Ausführung ein offline-Satz
> > war (der ja dann weg ist):
> > 
> > var "#" $i
> > if "#0" var "#1"
> > f1nd
> > dis
> > sho rec
> > 
> > B.E.
> > _______________________________________________
> > Allegro mailing list
> > Allegro at biblio.tu-bs.de
> > http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro
> 
> 
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro