[Allegro] V32.4 und Indexparameteraufruf

[Bernhard Eversberg]

Am 18.05.2012 11:04, schrieb Thomas Berger, s.u.:

Nun gut, damit haben Sie die Maximalforderungen komplettiert und erneut
einen staunenswerten Überblick bewiesen über alles, was passieren
könnte und vielleicht nicht sollte oder aber unbedingt müßte. Und auch
zugegeben, diesen Überblick sollten wir wohl als Entwickler selber
besitzen und bei jedem Schritt im Auge haben.
Gleichwohl, und abermals zugegeben, ich sehe nicht, wie alles das
in überschaubarer Zeit auf die Reihe gebracht werden und dann auch
noch übersichtlich bleiben könnte.
Die Forderung, alles das müsse acon reibungsfrei, transparent,
effizient und fehlerlos bewältigen, ist zur Stunde unerfüllbar.

Wir können nur anraten: VORSICHT beim Updaten mit acon, wenn man
zeitgleich andere Updates laufen läßt oder wenn an der Datenbank
ein oder mehrere gleichzeitig arbeiten und dabei womöglich Dinge
machen, die in den beschriebenen Aspekten kritisch sind. Denn das sind
die Fälle, in denen die unten geäußerten Vorbehalte greifen könnten.
Vermeidet man das, operiert man also in diesem Sinne defensiv, ist der
jetzt erreichte Status, wir wir meinen, hinreichend sicher, jedenfalls
sicherer als der alte mit UPDATE.EXE. Wer mit jenem keinen Ärger hatte,
wird mit diesem auch keinen kriegen, und das ist doch schon mal was.
Wer diese Ansicht nicht teilt, sollte besser sofort aufhören, mit UPDATE
irgendwas einzuspeisen. Oder mit PRESTO zu arbeiten, denn dabei gilt
ja ebenfalls einiges, was Sie schreiben.

B.E.


>
>> Es geht nicht nur um die get-Befehle (in Bezug auf diese sehen Sie es
>> schon richtig), auch in anderen Situationen (vor allem  find #nummer)
>> kann es sein, daß anschließend sofort bearbeitet und gespeichert werden
>> soll. Wir müssen daher doch einen Schalter haben, der normalerweise auf
>> "off" steht, und auf "on" gesetzt werden kann, wenn das prophylaktische
>> Errechnen sein muß. Genau hier sind noch nicht alle Einzelheiten
>> durchgecheckt, die vorgelegten Texte deshalb auch noch nicht komplett.
>
> Das prophylaktische Errechnen *darf nicht* sein, denn es geht ja darum,
> beim Speichern die Schluessel auszutragen, die entfallen, und die
> koennten (entsprechend perfekte Pseudoschluessel- und andere Mechanismen
> vorausgesetzt) durchaus andere sein als zum Zeitpunkt der Datensatz-
> sperre.
>
> Wir wissen aber, dass die Pseudoschluessel-Mimik ziemlich wenig perfekt
> ist und koennen daher durchaus tolerieren, dass die Schluessel bereits
> bei der Datensatzsperre berechnet werden, wenn das dem traditionellen
> Ablauf eher entspricht. Mit "get edit" etc. haben wir aber schon seit
> sehr langer Zeit genau das Kommando, das diesen zusaetzlichen Sicherheits-
> bedarf ausdruecken kann: Naemlich den Bedarf einer (Offline-)Routine,
> bereits vor dem Versuch einer Aenderung am Datensatz Klarheit darueber
> zu gewinnen, ob das anschliessende Speichern funktionieren wird. Oder
> den Bedarf, in eigener Regie Vergleiche zwischen Datensaetzen vorzunehmen,
> ohne dass diese spontan veraendert werden: Typischer Vertreter fuer
> diesen Fall ist UPDATE in den Modi -fm3.. und -fm4.. sowie in den
> Faellen, wo noch eine Parameterdatei dazugeschaltet wird, die auf Grundlage
> von "vorhandener Datensatz" und "neuer Datensatz" Auswertungen und/oder
> Manipulationen vornimmt.
>