Re: [Allegro] im vorfeld den/das längster datensatz/längstes feld ermitteln?

Sa Mai 25 19:07:39 CEST 2013

Guten Tag Frau Koczian,
danke für Ihre Nachricht.
Am Samstag, 25. Mai 2013 um 11:32 schrieben Sie mir.
Ihre Nachricht finden Sie am Ende dieser eMail.

> Lieber Herr Lehmann, liebe Liste,
> Am 25.05.2013 10:57, schrieb Klaus Lehmann:
>> werte kollegen
>> ein kleines problem, kommt nicht oft vor....

> Funktioniert der Export in eine alg-Datei, bleiben dabei alle 
> Problemdaten erhalten? Wie groß ist diese Datei? 40.000 Datensätze 
> scheinen mir für sich genommen noch nicht problematisch.

evtl sind die inhalte problematisch. die kollegen haben begeistert aus 
dem internet kopiert. jeder zeilenumbruch(?) auf dem bildschirm ist 
als hex14 (ascii20) abgespeichert worden. un diese gibts haufenweise IN 
der datensatzkategorie #4nz.
ich habe ca 10 datensätze gefunden, die mengenmäßig (für den gesamten! 
datensatz) bei über 10.000bytes [im editor wird in columnen gezählt!] 
waren. mein letzer fall ist aber bei 8.800 columnen. also weit UNTER der 
von h. eversberg definierten 10.000-bytes-grenze. deshalb habe ich 
noch mal direkt in der liste nachgefragt! das was ich hier gerade 
erlebt, lässt bei mir derzeit nur den schluss zu, daß die 
max.datenfeldgrenze bei DEUTLICH Unter 10.000bytes liegt.

> alg-Datei Zeile für Zeile nehmen, an allen ASCII-Nullen trennen und für
> jeden der Strings die Länge mit einer vorgegebenen Untergrenze 
> vergleichen. Das sieht einfach aus und deshalb denke ich, so einfach 
> kann die Angelegenheit wohl nicht liegen.
mit dem tip, doch den export auf #4nz zu begrenzen, komme ich auf ca 
3.600 kandidaten. die sind wesentlich einfacher mit einem editor zu 
durchforsten...

> Dann ist noch zu klären, wie viel von dem Satz mit einem überlangen Feld
> ausgegeben werden muss, damit man ihn eindeutig identifizieren kann. 
> Primärschlüssel vorhanden? Und was genau dann mit ihm passieren soll: in
> eine Datei schreiben, diese Datei editieren und als Update-Grundlage 
> nehmen? Oder sind die Feldinhalte so, dass sie automatisiert 
> abgeschnitten werden können?

> Ein Nebenprodukt wäre Klarheit darüber, wie viele Felder dieses Kalibers
> Sie haben.
tja, das war eben die frage, ob es ein werkzeug gibt.
vielleicht hilft der ansatz von herrn eger weiter, die lebende 
datenbank mit dem api-zusatz mal zu durchindexen....
evtl später mehr dazu.

> Wenn es wirklich alles nur Felder #4nz sind, dann könnte man die 
> Längenprüfung für andere Felder auch bleiben lassen. Und vielleicht den
> Export auf diese Kategorie und den Primärschlüssel beschränken.
jepp. das war erstmal sehr gut!

zwi-gruß
k.lehmann

-- 
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 * Kleinwolmsdorfer Str. 37
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. Only with allegro. Yes we do. Always with allegro.
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 with VuFind
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki
* 2013: allegronet ist ein eingetragenes Warenzeichen

Am Samstag, 25. Mai 2013 um 11:32 schrieben Sie:
> Lieber Herr Lehmann, liebe Liste,

> Am 25.05.2013 10:57, schrieb Klaus Lehmann:
>> werte kollegen
>>
>>
>> ein kleines problem, kommt nicht oft vor....
>>
>> ich habe eine datenbank in der a-konfig vorzuliegen. und weiss, es
>> gibt überlange datenfelder. mit lk.flx kommt man teilweise an sie
>> heran. teilweise! das editieren in a99/presto gelingt nicht:
>> totalabsturz der beiden programme.
>> was bleibt einem noch? ein export der daten. ok. eine alg-datei
>> entsteht.
>> mit den hinweisen aus lk.flx kommt man teilweise an die betreffenden
>> datensätzen. und trotzdem! es bleibt ein rest von unerkannten
>> überlangen datenfeldern. "datenfeldern", NICHT datensätzen.
>>
>> der welt da draussen ist die struktur der allegor-datensätze wurst.
>> also überlege ich, wie ich an die längsten "datensätze" physikalisch herankomme.
>> kennt jemand ein instrument, wie man diese heraus bekommt?
>>
> Nein. Aber ich habe das ungute Gefühl, dass in Ihrer Beschreibung 
> problematische Punkte fehlen könnten. Denn so, wie Sie es beschreiben,
> wäre das doch für gängige Skriptsprachen nicht schwierig. Zumindest 
> nicht für die, die sich an einer ASCII-Null mitten in einem String nicht
> stören.

> Funktioniert der Export in eine alg-Datei, bleiben dabei alle 
> Problemdaten erhalten? Wie groß ist diese Datei? 40.000 Datensätze 
> scheinen mir für sich genommen noch nicht problematisch.

> alg-Datei Zeile für Zeile nehmen, an allen ASCII-Nullen trennen und für
> jeden der Strings die Länge mit einer vorgegebenen Untergrenze 
> vergleichen. Das sieht einfach aus und deshalb denke ich, so einfach 
> kann die Angelegenheit wohl nicht liegen.

> Dann ist noch zu klären, wie viel von dem Satz mit einem überlangen Feld
> ausgegeben werden muss, damit man ihn eindeutig identifizieren kann. 
> Primärschlüssel vorhanden? Und was genau dann mit ihm passieren soll: in
> eine Datei schreiben, diese Datei editieren und als Update-Grundlage 
> nehmen? Oder sind die Feldinhalte so, dass sie automatisiert 
> abgeschnitten werden können?

> Ein Nebenprodukt wäre Klarheit darüber, wie viele Felder dieses Kalibers
> Sie haben.

> Wenn es wirklich alles nur Felder #4nz sind, dann könnte man die 
> Längenprüfung für andere Felder auch bleiben lassen. Und vielleicht den
> Export auf diese Kategorie und den Primärschlüssel beschränken.

> Beste Grüße,
> Koczian
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro