[Allegro] Views

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

>> Klingt plausibel. Allerdings gibt es m.W. die "View-Erstellungsfunktion"
>> nicht.
> Ich meinte die in view.rtf

Dort aber z.B. view2.flx, das nicht im Arbeits- sondern im TEMP-
Verzeichnis agiert...



>> Frueher (m.W. heute nicht mehr) war das Verhalten, wenn die Eintraege
>> in einem View nicht alle gleiche Zeilenlaenge hatten, nach meiner
>> Erinnerung u.U. mit Umkopieren ins WorkDir verbunden, das war dann
>> aber fatal (wenn im DbDir eine neue Version erzeugt wird, nutzen
>> alle bis ultimo immer noch die umkopierte, alte).
>>
> Stimmt, man muß damit schon etwas aufpassen. Neue und veränderte Views,
> vor allem wenn sie dann von mehreren genutzt werden sollen,
> nach der ersten Benutzung mal kontrollieren, ob eine neue Version
> auf dem WorkDir entstanden ist. Dann diese auf den intendierten Pfad
> kopieren.

[Das Problem ist ja weniger das Zurueckkopieren an den gewuenschten
Ort, sondern die Entsorgung automatisch angelegter Kopien in einer
unbekannten Anzahl unbekannter Arbeitsverzeichnisse auf vielen
Arbeitsstationen, von denen mindestens eine ausgeschaltet ist und
ein anderer erst nach Ende des Erziehungsurlaubs diese Datenbank
wieder nutzen wird: Wir hatten das alles schon einmal im Zusammenhang
mit der Aufbewahrungsmimik von a99, die dann zu offcheck.flx fuehrte]

D.h. es ist noch heute so, dass ich, wenn ich eine View-Datei im
Datenverzeichnis habe, die aber zeilenlaengentechnisch "unguenstig"
ist, automatisch eine "verbesserte" Kopie im Arbeitsverzeichnis
angelegt und benutzt wird?

Ich habe das soeben einmal getestet:

D.h. in der Demo-Datenbank .vw-Dateien unterschiedlicher Qualitaet
im Datenverzeichnis abgelegt und auf verschiedene Arten genutzt:

1.
Aufruf: View name
bei zeilenlaengentechnisch "unguenstigen" .vw-Dateien werden im
Arbeitsverzeichnis verbesserte Kopien abgelegt und genutzt, auch wenn
die Version im Datenverzeichnis sich aendert.

Sonderfall: eine 0 Bytes grosse .vw-Datei gilt auch als "ungeunstig",
wird ins Arbeitsverzeichnis kopiert.

2.
Aufruf: var D "name"\View

Die "unguenstigen" .vw-Dateien werden an ihrem Ort "on the fly"
verbessert, d.h. die Originaldateien im Datenverzeichnis sind
anschliessend veraendert, eine Kopie wird nicht erzeugt.

3.
Aufruf im Formular: #kkf"blabla"|Vname

Wie 1.


4.
Interaktive Bearbeitung: view name\View 1
Analog 1: Es wird ggfls. ins Arbeitsverzeichnis umkopiert
(Bearbeitungen, die Zeilen verlaengern, sind nicht moeglich,
schon im Bearbeitungsfenster wird gekappt bzw. aufgeblasen)

5.
Interaktive Bearbeitung: var D name\view\View 1
Analog 2 und 4: Aenderungen landen in der (evtl. bereits egalisierten)
Originaldatei, es wird nichts ins Arbeitsverzeichnis umkopiert


Meine Schluesse:

a) Ich halte das Verhalten bei 1. und 3. aus den erwaehnten Gruenden
fuer problematisch, das Verhalten bei 2. zeigt, dass es auch anders geht
(Diesmal nicht ueberprueft, ob irgendwelche access-Setzungen die
Aufrufe mit Pfaden bei 2. verhindern).

b) Ich kann in Flexen alles auf "Namen mit Pfaden" umstellen, in
Formularen jedoch muss ich die "Automatik" einsetzen, weil es
keine Syntax fuer die "Angabe mit Pfad" gibt. Gerade im Formular
jedoch ist die atypische Suchreihenfolge (Arbeitsverzeichnis
zuerst) nicht wirklich ueberzeugend.

c) Der Sonderfall mit der korrupten/leeren .vw-Datei sollte
abgefangen werden

d) Ich bin mir ueberhaupt nicht mehr im Klaren darueber, wozu
die feste Zeilenlaenge in View-Dateien nutzen soll, dass der
Anwender im Fenster gezielt zu Zeile xy springen will, mag
ja meinetwegen vorkommen, aber Zeilen-Zaehlen vom Dateianfang
aus kann ja nicht wirklich ein Performance-Killer sein, zumal
wo auch noch eine Volltextsuche angeboten wird, die gewiss
langsamer ist.


viele Gruesse
Thomas Berger


P.S.: Meine Situation mit 0 Byte grossen .vw-Dateien hat sich nun
voellig klaeren lassen:

Es geht um "Picklisten" mit Kuerzeln und Codes (Satzarten,
Funktionsbezeichnungen von Personen und Koerperschaften, die zur
Nutzung in Formularen als View hinterlegt sind. Der "gueltige Stand"
der Codes steckt jedoch in Form von Datensaetzen in der Datenbank
(damit z.B. bei der Anzeige von Datensaetzen die Codes auch
aufgeloest und gegendert gezeigt werden koennen). Bei der
Aktualisierung der Datenbank werden die View-Dateien daher
automatisch geloescht und muessen ueber ein Menue wiederhergestellt
werden. Die Codes fuer die Satzarten sind allerdings auch fuer
das F9-Menue relevant, fehlt der View, so wird darauf hingewiesen,
dass zunaechst die View-Liste erzeugt werden muss. In dieser
Situation nahm dann das Verhaengnis seinen Lauf: Der Generierungs-Flex
nutzt eine Exportparameterdatei, um im Datenverzeichnis eine
"guenstige" .vw-Datei mit konstanter Zeilenlaenge als aufbereiteten
Registerauszug abzulegen, d.h. es ist eine Parameterdatei, die ausgehend
von einem beliebigen, als "Anker" genutzten Datensatz die Ausgabe
produziert. In der oben geschilderten typischen Situation ist aber
der aktuelle Datensatz ein deaktivierter oder geloeschter, der
Export fand nicht statt und es entstand eine leere .vw-Datei im
Datenverzeichnis. Probierte man dann spaeter Alt-i im Formular, so
passierte nichts (aber im Hintergrund wurden leere .vw-Dateien
ins Arbeitsverzeichnis kopiert), spaeteres erfolgreiches Generieren
der View-Dateien half dann auch nichts mehr (weil die im
Arbeitsverzeichnis vorhandenen View-Dateien die Sicht auf die
inzwischen korrekten im Datenverzeichnis versperrten).






-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSUJLDWITJZieluOzAQIvwwP/dnbJpxR3WNDHLsIR55oGJs7EX6u9a67C
uQRnaNmX1RuYBdh6dMgfhcUMz0UCsuVC0g6RpWCV/oKZvge74sY6k22zc/inHGmg
PQwAExm/8q7DOh5d2/DR+6LFiXjlX9GVUT1CYLGLh4bBUoPyovREmoOEIJdhz1Ot
Y/WCs+KUMeg=
=xkYR
-----END PGP SIGNATURE-----