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

[Thomas Berger]

Liebe Frau Koczian,


> 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).

interessant genug, dass "f1nd" anscheinend doch kein "get" impliziert,
denn "set getlock" hat in der Tat keinen Einfluss darauf.


> 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.

... und auch waehrenddessen: die .TBL scheint die ganze Zeit ueber gesperrt,
bis das "f1nd" dann am Timeout scheitert.


> 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.

wohl eher letzeres, denn ich kann mir nicht vorstellen, warum ein Satz
gesperrt werden sollte durch einen Job, der gerade wegen des "set a1"
diesen Satz gar nicht mehr schreiben darf. Konsequenterweise funktioniert
ja auch ein Neu-Laden des fraglichen Satzes nicht, da acon nicht einsieht,
dass Buchfuehrung bezueglich der Tatsache, ob der aktuelle Job oder ein Fremder
einen Satz gesperrt hat, den Unterschied zwischen "brauchbarer" und "sinnloser"
Implementierung von Locking ausmacht.

Auffaellig ist uebrigens auch, dass bei f1nd (anders als bei find)
das "set a1" nicht durch den naechsten Ladebefehl aufgehoben wird.

Fazit: "f1nd" ist ja sowieso nur eine Kruecke aus der Zeit, als nur eine
Ergebnismenge moeglich war. Also einfach nicht benutzen!

viele Gruesse
Thomas Berger