AW: Kategorien in Exportparameter- und Konfigurationsdateien

[Thomas Berger]

Lieber Herr Fischer,

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

In Bezug auf die .CFG ist das Ihr Standpunkt, in Bezug auf
die Exportparameter ein Widerspruch. "Meine" Denkweise ist,
dass Parameterdateien weniger statisch sind als .CFG's,
einheitliche .CFG's waeren mir wichtiger als einheitliche
Parameter, am wichtigsten jedoch, dass ich .CFGs moeglichst
nie fundamental aendern muss, also ruhig noch ein paar
Reserve-Kategorien inkauf nehme.

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

Dass "use strict" nicht Default ist, gilt in Perl als Bug,
der aber dringelassen wird, damit alte Anwendungen nicht
zerbrechen.


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

...

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

Naja, es sollten immer 7 Zeilen sein, die Frage ist also
eher, wo die Toleranzgrenzen der einzelnen Module sind,
bzw. warum nicht alle einheitlich abstuerzen, das waere
konsistenter.

viele Gruesse
Thomas Berger