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

[Anando Eger]

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