[Allegro] Probleme: Win10 (Version 1809 -sic) Fonts werden nicht akzeptiert. a99.exe läuft nur mit normalo-Fonts(arial)

Di Okt 16 13:45:10 CEST 2018

Hallo Herr Lehmann,

zu Ihrem Satz
> meine cfg ist strikt alpahabetisch sortiert

fällt mir ein:

Die Ordnung in der cfg bestimmt das Verhalten der bedingten Postfixe 
... s. HB 10.2.6.1.

Die Routinen im A99, die die Exportparameter interpretieren, zeigen 
schlecht reproduzierbares, irreguläres Verhalten, wenn die 
Reihenfolge der Kategorien im Datensatz nicht mit der Ordnung in der 
cfg übereinstimmt.

Üblicherweise verschwinden dadurch verursachte Effekte, wenn man die 
Datenbank neu aufgebaut hat.

Könnte das hier (zufällig) der Fall gewesen sein?

Viele Grüße
Anando Eger

-------------------------------------------------------------------
Anando Eger Datenverarbeitung
Herr Dipl.-Ing. Anando Eger
Gustav-Voigt-Str. 24
01156 Dresden
Tel.: +49 (0)351 454 1236  http://www.aneg-dv.de
Fax: +49 (0)351 454 1238  mailto:a.eger at aneg-dv.de
-------------------------------------------------------------------
== Wir sprechen deutsch. ==

Datum:   	Tue, 16 Oct 2018 11:45:52 +0200
Von:            	Klaus Lehmann <lehmann_klaus at t-online.de>
Organisation:   	allegronet.de
An:             	Diskussionsliste Allegro-C 
<allegro at biblio.tu-bs.de>
Betreff:        	Re: [Allegro]
	Probleme: Win10 (Version 1809 -sic) Fo
	nts werden nicht akzeptiert. a99.exe läuft nur mit 
nor
	malo-Fonts(arial)
Antwort an:     	Allegro-C Diskussionsliste 
<allegro at biblio.tu-bs.de>

[ Doppelklick auf diese Zeile zeigt Optionen für Abo-Liste ] 

Guten Tag Herr Eversberg,
Danke, daß Sie sich dem dringenden Problem angenommen haben.

Ihr "Workaround" funktioniert wahrscheinlich am besten, bei
denjenigen, die ein "normales" allegro ohne große Änderungen in der
cfg und frm haben. Dieses ist bei mir leider nicht der Fall.

Deshalb gestatte ich mir, meinen "Workaround" (=blödes Wort)
vorzustellen.
Dazu info:
1. meine cfg ist strikt alpahabetisch sortiert. bei einer doch 
größeren cfg
findet man sonst nix auf die schnelle. Tja, was ist aber 
"alphabetisch"?
z.b. sowas:
#80
...
#89
#8a
...
#8z
wenn man sich die asciiliste anschaut, ist meine sortierung nicht 
ganz
falsch ;-)
zuerst Ziffern, dann große buchstaben und dann kleine buchstaben.

2. die frm könnte man zwar ähnlich (in der abfrage) alphabetisch
aufbauen, aber es wäre NICHT komfortabel in der abfolge der
nötigen(gewohnten) arbeiten eines bibliothekars ;-)
also, ist die frm selten sortiert.

nun zum workaround:
in der abteilung meiner frm, die die RDAinhalte abfragt, habe ich
zuoberst #99g "#99g"PlaceboInhalt reingesetzt. sodaß es jetztg so
aussieht:

[Buch, Teil 2]
#99g"#99g"PlaceboInhalt
#73.1 "erweit. ErschAngabe."
#0c.1 "Inhaltstyp"|Vctype
#77.1 "Datentr.Typ"|Vmtype

wichtig ist dabei: ich nehme mir ein feld, was relativ weit unten am
ende der cfg kommt, und lasse einen placeboinhalt automatisch in den
datensatz einfügen (ohne letzteres geht es NICHT!)
und voila.
was leider unschön ist, ich verschwende eine wertvolle zeile in 
einer
frm-abteilung (man hat jeweils nur 14 zeilen!) und man hat "stuss" 
in
der datenbank, der irgendwannmal gelöscht werden sollte.... ;-(

trotzdem: der (meine) workaround funktioniert nach den testen tests
;-)

prima, ich danke.
weil: nichts ist schlimmer, als leere felder in der datenbank zu
haben! sie können marc-exporte zum "krachen" bringen (mein
"lieblingsthema")....

viele dankbare grüße
ihr klaus lehmann

PS: ich bin mir nicht sicher, daß diese nachfolgende schweibweise OK
ist:
#77.1 "Datentr.Typ"|Vmtype
     1x LEER hier.

muss es evtl so heissen:
#77.1"Datentr.Typ"|Vmtype
    KEIN LEER hier....

???

danke für Ihre Nachricht.
Am Dienstag, 16. Oktober 2018 um 09:09 schrieben Sie.
Ihre Nachricht finden Sie am Ende dieser eMail.

> Kollege Lehmann:
 >> 
 >> PS: leider ungeklärt:
 >> sind in der frm-datei solche konstruktionen zu finden, wie 
diese:
 >> (aus der cat.frm)
 >> [Buch, Teil 2]
 >> #73.1 "erweit. ErschAngabe."
 >> #0c.1 "Inhaltstyp"|Vctype
 >> #77.1 "Datentr.Typ"|Vmtype
 >> 
 >> ist an der 5.stell EIN leer oder KEIN leer, dann werden LEERE 
felder wie
 >> #73.1
 >> #0c.1
 >> #77.1
 >> links oben in a99.exe erzeugt. sie enthalten KEIN leer.
 >> das ganze passiert NUR, wenn auf dem Button "Neusatz(F9)" klick.

> Dazu ein Zwischenbericht:
> Das passiert NUR, wenn zum Zeitpunkt der leeren Eingabe eines dieser Felder im
> entstehenden Datensatz noch kein Feld vorhanden ist, das unterhalb #77.1 in
> der CFG-Reihenfolge stünde. Der tieferen Ursache bleibt weiter nachzuspüren,
> deshalb erstmal nur ein AbhilfeTip:
> Oberhalb von #73.1 ein Feld einsetzen, z.B. #87 oder #85 oder beide, das in
> der CFG-Reihenfolge unter #77 steht.
> Oder: #73.1 usw. in der CFG weiter nach oben rücken, es darf ruhig über der #20
> sein. Sieht dann zwar komisch aus, tut aber der Funktionalität keinen
> Abbruch, und Reorganisation ist nicht erforderlich. 

> NACH einer noch ausstehenden definitiven Lösung KÖNNTE man eine Reorganisation
> ("Datenbank ganz neu aufbuen") machen, muß man aber auch nicht! Es würde genügen,
> in der CFG die alte Reihenfolge wiederherzustellen.

> Für Verblüffte: Die im Programm sichtbare Reihenfolge ist immer diejenige,
> die momentan in der CFG eingestellt ist, egal in welcher Reihenfolge die
> Felder physisch in der Datenbank (.ald-Datei) vorliegen. Anders gesagt:
> Es ist entgegen der Intuition NICHT so, daß die Felder automatisch alphanumerisch
> sortiert würden, sondern sie werden im Arbeitsspeicher beim Einlesen oder Eingeben
> in der Reihenfolge der CFG sortiert und dann auch so gespeichert. Bei erneutem
> Einlesen nach Änderung der CFG und Neustart des Programms wird ein Satz dann eben
> in der geänderten Reihenfolge gezeigt und im Falle daß man speichert, auch so gespeichert.

> B.E.

>  
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> https://bibservices.biblio.etc.tu-bs.de/mailman/listinfo/allegro

> Um sich von dieser Liste abzumelden, klicken Sie hier:
> mailto:allegro-request at biblio.tu-bs.de?subject=unsubscribe

> To unsubscribe from this list, click here:
> mailto:allegro-request at biblio.tu-bs.de?subject=unsubscribe

-- 
Mit freundlichen Grüßen,
Ihr Klaus Lehmann
http://allegronet.de * eMail: allegronet at t-online.de * phone: 
03528-452 807(fax 809) * mobil: 0171-953 7843
allegronet.de * Klaus Lehmann * D-01454 Radeberg * Bahnhofstr. 1
zuständiges Finanzamt: FA Hoyerswerda; zuständige Kammer: IHK 
Dresden;
zuständige Aufsichtsbehörde: Gewerbeamt Radeberg; USt-IdNr: 
DE247550760
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow. Yes we 
can!
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 mit VuFind
* 2011-12:  Sponsor: Peter-Sodann-Bibliothek+IFLA:allegro-utf8
* 2013-14: Bolero 64bit.+allegro-zdb: endlich. + eBooks
* 2015-16: allegro-vufind.+ allegro-imd.Die weltgrößte(?) 
Filmdatenbank
* 2017-18: Exporte. Marc und Co.  Marc ist sehr different
Lesen Sie auf 
http://portal.allegronet.de/allegrowerkstatt/allegro-windows die
Wahrheit zur Zukunft von allegro-C. Bilden Sie sich Ihre eigene 
Meinung! Lesen Sie!

Am Dienstag, 16. Oktober 2018 um 09:09 schrieben Sie:
> Kollege Lehmann:
 >> 
 >> PS: leider ungeklärt:
 >> sind in der frm-datei solche konstruktionen zu finden, wie 
diese:
 >> (aus der cat.frm)
 >> [Buch, Teil 2]
 >> #73.1 "erweit. ErschAngabe."
 >> #0c.1 "Inhaltstyp"|Vctype
 >> #77.1 "Datentr.Typ"|Vmtype
 >> 
 >> ist an der 5.stell EIN leer oder KEIN leer, dann werden LEERE 
felder wie
 >> #73.1
 >> #0c.1
 >> #77.1
 >> links oben in a99.exe erzeugt. sie enthalten KEIN leer.
 >> das ganze passiert NUR, wenn auf dem Button "Neusatz(F9)" klick.

> Dazu ein Zwischenbericht:
> Das passiert NUR, wenn zum Zeitpunkt der leeren Eingabe eines dieser Felder im
> entstehenden Datensatz noch kein Feld vorhanden ist, das unterhalb #77.1 in
> der CFG-Reihenfolge stünde. Der tieferen Ursache bleibt weiter nachzuspüren,
> deshalb erstmal nur ein AbhilfeTip:
> Oberhalb von #73.1 ein Feld einsetzen, z.B. #87 oder #85 oder beide, das in
> der CFG-Reihenfolge unter #77 steht.
> Oder: #73.1 usw. in der CFG weiter nach oben rücken, es darf ruhig über der #20
> sein. Sieht dann zwar komisch aus, tut aber der Funktionalität keinen
> Abbruch, und Reorganisation ist nicht erforderlich. 

> NACH einer noch ausstehenden definitiven Lösung KÖNNTE man eine Reorganisation
> ("Datenbank ganz neu aufbuen") machen, muß man aber auch nicht! Es würde genügen,
> in der CFG die alte Reihenfolge wiederherzustellen.

> Für Verblüffte: Die im Programm sichtbare Reihenfolge ist immer diejenige,
> die momentan in der CFG eingestellt ist, egal in welcher Reihenfolge die
> Felder physisch in der Datenbank (.ald-Datei) vorliegen. Anders gesagt:
> Es ist entgegen der Intuition NICHT so, daß die Felder automatisch alphanumerisch
> sortiert würden, sondern sie werden im Arbeitsspeicher beim Einlesen oder Eingeben
> in der Reihenfolge der CFG sortiert und dann auch so gespeichert. Bei erneutem
> Einlesen nach Änderung der CFG und Neustart des Programms wird ein Satz dann eben
> in der geänderten Reihenfolge gezeigt und im Falle daß man speichert, auch so gespeichert.

> B.E.

>  
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> https://bibservices.biblio.etc.tu-bs.de/mailman/listinfo/allegro

> Um sich von dieser Liste abzumelden, klicken Sie hier:
> mailto:allegro-request at biblio.tu-bs.de?subject=unsubscribe

> To unsubscribe from this list, click here:
> mailto:allegro-request at biblio.tu-bs.de?subject=unsubscribe

_______________________________________________
Allegro mailing list
Allegro at biblio.tu-bs.de
https://bibservices.biblio.etc.tu-bs.de/mailman/listinfo/allegro

Um sich von dieser Liste abzumelden, klicken Sie hier: 
mailto:allegro-request at biblio.tu-bs.de?subject=unsubscribe

To unsubscribe from this list, click here: 
mailto:allegro-request at biblio.tu-bs.de?subject=unsubscribe
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20181016/c09ddd68/attachment.html>