Re: [Allegro] erase löscht 'gelockte' Sätze

[Anando Eger]

Hallo Herr Berger, lieber Herr Eversberg,

wie groß ist eigentlich das Zeitfenster beim Vergleich
der Zeitstempel bzw. wie hoch löst der Zeitstempel auf?

Was dazu noch paßt: Ein Befehl ähnlich des avanti-"get edit"
wäre sehr hilfreich. Im Moment benutze ich folgende etwa 
äquivalente Konstruktion für a99:

...
var "(suchschlüssel)"\f1nd\if no jump gibts_nicht
set rec lock\if no jump nicht_frei
var "#" i\f1nd\if no jump sollte_eigentlich_nicht_passieren
... 

Zusammen mit der hier nicht dargestellten Fehlerbehandlung 
sind das mindestens 10 Zeilen - man könnte ca. 2/3 sparen.

Oder kennt jemand etwas kürzeres?

Herr Eversberg, was meinen Sie?  Könnte man vielleicht
über einen set-Befehl den f1nd-Befehl so einstellen, daß
er des Satz gleich beim Laden lockt?

Viele Grüße
Anando Eger


On 14 Mar 2007 at 22:31, Thomas Berger wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Lieber Herr Eger,
> 
> >>> "put" speichert doch einen verriegelten Satz auch nicht - 
> >>> wäre es nicht besser, wenn "erase" analog funktionieren
> >>> würde?
> >> Ich stelle es mir nicht schoen vor, wenn ein Satz
> >> von PRESTO abgespeichert wird an eine Stelle, die
> >> durch Recycling desselben, zwischenzeitlich geloeschten
> >> Satzes mittlerweile ein ganz anderer gueltiger Satz
> >> ist...
> > 
> > eben, und etwas ähnliches passiert leider, nicht mit presto, 
> > sondern mit a99 ... :-(
> 
> das darf aber aus ganz anderen Gruenden eigentlich auch
> nicht passieren: a99 sollte beim Speichern den
> Zeitstempel vergleichen und das Abspeichern verweigern
> (zumindest wenn der Leersatz nach dem Loeschen inzwischen
> wieder in Benutzung geraten ist)
> 
> 
> > Ich plädiere dafür, daß erase mindestens den Zeitstempel
> > prüft und den Lock-Zustand berücksichtigt.
> > 
> > Das gleiche trifft auf den Menüpunkt "Löschen"/"Aktivieren zu.
> 
> Angenommen, der loeschwuetige Benutzer L ist eher langsam, starrt
> lange auf die Aufnahme und drueckt dann bedaechtig auf "Entf":
> 
> a) Der bearbeitungsfreudige Benutzer B hat die Aufnahme zwischen-
>    zeitlich in den Klauen gehabt und abgespeichert.
>    Dann koennte ein recht universell einzusetzender Mechanismus
>    dem Benutzer L sagen, "Geht nicht, Satz wurde zwischenzeitlich
>    veraendert", so wie L das auch bei/nach einer normalen
>    Bearbeitung passieren wuerde.
> 
> b) Bearbeiter B hat noch nicht abgespeichert
>    ba) mit PRESTO: Der Satz ist gesperrt, er *kann* nicht
>        geloescht werden (ganz analog zum Speichern), das
>        ist unabhaengig davon, ob L mit PRESTO oder a99 die
>        Loeschung versucht.
> 
>    bb) mit a99: Niemand weiss, ob B jemals speichern wird, der
>        Satz kann geloescht werden, weil es keine Anhaltspunkte
>        gibt, die dagegen spraechen.
>        Beim Speichern durch B muss a99 (waehrend die .TBL-Datei
>        gesperrt ist) testen, ob der Satz noch aktiv ist (nicht nur,
>        ob gesperrt und ob der Datumsstempel noch stimmt)
> 
> Beim "Aktivieren" sollte ebenfalls "tief unten" (also waehrend
> die .TBL-Datei gesperrt ist) getestet werden, ob der Satz ueberhaupt
> noch geloescht ist. Ansonsten kann es insbesondere unter PRESTO,
> das ja wegen "rec lock" die Datumsstempel nicht vergleichen muss,
> zu Mehrfachnutzungen kommen.
> 
> viele Gruesse
> Thomas Berger
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3-nr1 (Windows XP)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFF+GnIhKFJT0F1FsoRAgvPAJ0e73umUTpVB47Koe9LbEC6fJxpPACfZmuo
> XIfuN8fVVKKk9SuMiztaFcs=
> =Zv5k
> -----END PGP SIGNATURE-----
>