[Allegro] Acon: Kein Entsperren am Ende des Jobs?

[Sibylle Koczian]

Liebe Liste, lieber Herr Berger,

Am 01.01.2013 18:20, schrieb Sibylle Koczian:
> Am 31.12.2012 16:48, schrieb Thomas Berger:
>>
>> Haben Sie da etwas entscheidendes nicht geschildert?

Genau dies stellt sich jetzt heraus.

> Ich werde jetzt erst mal einerseits die zum Thema passende Verlautbarung
> zu finden versuchen und andererseits noch etwas testen.
>

Ergebnis: es gibt schon ein unerwartetes Verhalten von f1nd, aber der 
Auslöser ist ganz anders als ich vermutet habe.

Erst mal: "set getlock" hat mit dem Sperren/Entsperren durch f1nd nichts 
zu tun, es wirkt auf get ... ohne edit. Also haben meine gesperrten 
Sätze mit einer Default-Einstellung "set getlock on" mal gar nichts zu 
tun, und diese Einstellung ist auch nicht Default (nicht ausprobiert, 
nur der Dokumentation entnommen).

Des Pudels Kern statt dessen: Der Job, der einen gesperrten Satz 
zurücklässt, gibt zwar nur ein paar Kategorien aus diesem Satz aus und 
ändert ihn nicht - aber er löst dabei ein Stammsatzkürzel auf. Und das 
führt dazu, dass der Satz nicht entsperrt wird.

Auszuprobieren an der Demo-Datenbank mit dem folgenden kleinen Job:

f1nd TIT tucho?
set a1
write #00 ": " #31p n

Dabei den Befehl "set a1" mal auskommentieren, mal aktiv lassen und 
hinterher in a99, z.B. mit "h org", den Sperrzustand des gefundenen 
Satzes überprüfen.

Ein "set unlock" am Ende des Jobs entsperrt den Satz. Aber soll das so 
sein oder nicht? Ich nehme an, das Verhalten hängt damit zusammen, dass 
ein Satz nach der Stammsatz-Auflösung ja nicht mehr gespeichert werden 
darf. Allerdings lässt "find" statt "f1nd" den Satz nicht gesperrt 
zurück. Sucht man im gleichen Job mehrere Sätze hintereinander mit f1nd, 
sind sie hinterher alle gesperrt (und ein "set unlock" am Ende entsperrt 
nur den letzten).

Mir scheint das schon unerwartet und deshalb entweder beschreibungs- 
oder korrekturbedürftig.

Beste Grüße,
Koczian