AW: Kategorien in Exportparameter- und Konfigurationsdateien

[Thomas Fischer]

Lieber Herr Berger,

>> Da ich auch die eine oder andere neue Kategorie einführen 
>> muss, bin ich wieder darauf gestoßen, dass Allegro 
>> Parameterdateien, die in der Konfiguration nicht vorgesehen 
>> Kategorien enthalten, als unzulässig zurückweist.
>> 
>> Dies wäre für mich aber gerade praktisch: was in der 
>> Datenbank nicht da ist, stört auch nicht, ist es da, kann es 
>> genutzt werden. Daher die Frage, ob diese Art der 
>> Sicherheitsprüfung wirklich sinnvoll und nötig ist. 
>> Vielleicht ist unsere Situation mit an die 20 verschiedenen 
>> Datenbanken unter einem Konfigurationsbuchstaben ja auch ungewöhnlich.


> Ich halte das fuer "sinnvoll und noetig", denn in einer 
> Exportparameter-
> datei hat man sich schnell vertippt.
 
Meine Vorstellung ist, dass man mit der Datenbank ständig arbeitet, die Exportparameter aber nur selten geändert werden. Daher möchte ich eigentlich keine neuen Kategorien einfügen, wo sie nicht hingehören.
 
> > Der logische Schritt ist dann, die neuen Kategorien in den 
> anderen Datenbanken für zulässig zu erklären, das ist dann 
> letzten Endes viel unsicherer als wenn nur die 
> Exportparameter akzeptiert würden.
> 
> Was meinen Sie mit "unsicherer"? Falls Sie befuerchten, dass ein
> Benutzer eine fuer diese Datenbank unerwuenschte Kategorie eingibt,
> koennen Sie das in der .CFG ueber die entsprechende Eigenschaft
> (m.W. $P15) verbieten.

Ich könnte da $P4 setzen (nur sichtbar), müsste auch noch einen Kommentar einfügen, warum die Kategorie da ist, aber eigentlich nicht da sein soll, sonst versteht das doch niemand. In jedem Fall zusätzliche Mühe. Am liebsten wäre mir eine Regelung wie bei Perl, wo man "strict" setzen kann oder auch nicht, und je nach Setzung nicht deklarierte Variablen zulässig sind.

 
> > 2. Startkategorien in Konfigurationsdateien
> > Als ich das tat, bin ich auf die Anfangskategorien 
>> gestoßen, die ohne Hierarchiestufen standardmäßig wohl so aussehen:
> > 
> > #u1
> > #u2
> > #00"Nummer"M
> > #00      wenn Sie nur EINE Unterstufe wollen; sonst hier auch #00
> > #00
> > #00
> > #00
> > 
> > Und ich fragte mich, was die wiederholten "#00" bedeuten 
>> und bewirken. 
 
> Es steht doch da (in der .CFG der Demodatenbank):
> 
>   !!! Folgende 9 Zeilen bitte nicht ändern (Hierarchie-Struktur für 6
> Stufen)
> #u1"Kopfzeile 1"
> #u2"Kopfzeile 2"
> #00"IdNr"
> #01"BandNr"
> #02"TeilNr"
> #03"3. Hierarchiestufe"
> #04"4. Hierarchiestufe"
> #05"5. Hierarchiestufe"
> #06"6. Hierarchiestufe"
> 
>   So müssen die Zeilen aussehen, wenn Sie KEINE Hierarchie wollen:
>   #u1
>   #u2
>   #00
>   #01     wenn Sie nur EINE Unterstufe wollen; sonst hier auch #00
>   #00
>   #00
>   #00
>   #00
> 
> D.h. hinter den Zeilen fuer #u1 und #u2 kommen 7 Zeilen, die evtl.
> alle #00 heissen und die Hierarchiestufen festlegen.

Dass hatte ich auch gefunden, aber nach der ganzen Beschreibung des Systems hat 
#00 
exakt die gleiche Bedeutung wie
#00
#00

Nach der dahinter stehenden Magie hatte ich fragen wollen, und danach, warum  procav.exe abstürzt, wenn zu wenige von diesen #00 in der Gegend sind.

Mit freundlichen Grüßen,
Thomas Fischer