TextLib

TextLib Hírlevél - 7. szám (2001. január)

A TextLib hírlevélnek a honlapon olvashatóval azonos szövegű nyomtatott változata a szoftvertámogatási díjat fizető könyvtárak számára készül.


Hírek, események

TextLib tanfolyamok

Lezajlott az első tanfolyam minden tervezett témából, ez együttesen öt összejövetelt jelent. Volt szó az olvasószólgálati munkáról, a rendszergazda feladatokról, az általános programhasználatról, az állománygyarapításról és a könyvek (meg egy bő fél napig más dokumentumtípusok) beviteléről. A tanfolyamok sorrendjét a jelentkezők száma határozta meg, egyelőre ugyanebben a sorrendben folytatjuk, de természetesen nem kell ehhez ragaszkodnunk.

Az öt rendezvényre 27 könyvtárból 80 könyvtáros jött el. Voltak könyvtárak, amelyek többször is küldtek résztvevőket, és természetesen olyan könyvtárosok is, akik egynél több tanfolyamon vettek részt. Eddig legtöbben a József Attila Megyei Könyvtárból érkeztek Tatabányáról, tízen, a Városi Könyvtárból Székesfehérvárról heten, a Budapesti Gazdasági Főiskola Külkereskedelmi Főiskolai Karának Könyvtárából pedig hatan.

Örülünk annak, hogy eddig csaknem mindig telt ház volt, csak néhány utolsó pillanatban lemondott helyre nem sikerült mindig új jelentkezőt találnunk. A március 5-én kezdődő olvasószolgálati tanfolyam létszáma már betelt, de a későbbiekre még bőven van hely. Várjuk jelentkezésüket!


3..2..1..start

A legújabb TextLibes könyvtárak

A legújabb TextLibes web szerverek


Mire jó a ...?

...TL_VESZ.LOG és a HM_VESZ.LOG szövegállomány?

Valószínűleg szükségtelen bizonygatni, hogy a bibliográfiai rekordok adatbázisba juttatásának legkényelmesebb módja az import. Ennek az állításnak az érvényességét nem csorbítja, hogy a rekordok betöltése sem mindig egyszerű. Sokféle bonyodalom adódhat, amelyekben azonban egy vonás közös: a nemkívánatos jelenségek okainak feltárása után az importálás körülményeit megváltoztatva a hiba egyszer és mindenkorra megszüntethető.

A nemkívánatos jelenségeket a betöltés eredményeként előálló adatbázis tartalmazza: rekordok többszöröződnek vagy eltünnek, nem összetartozó rekordok összekapcsolódnak vagy összetartozók elszakadnak egymástól, egy rossz mezőtartalom diadalmaskodik a jó felett vagy a jó indokolatlanul érvényesülni engedi a rosszat. Bármi is a tünet, három helyen lehet a baj okát keresni:

De melyikben a három közül? Lehet, hogy csak az egyikben, és az is lehet, hogy többen is. Ebben a pillanatban jutottunk el a címben foglalt kérdéshez, most kellene elővennünk a TL_VESZ.LOG vagy a HM_VESZ.LOG nevű szövegállományt.

Előtte azonban egy kis kitérőt teszünk. Az eddigiekből nagyjából kiderült, de a biztonság kedvéért határozzuk meg pontosan a két szövegállományt. Mindkettő importáláskor keletkezik, részletes naplója a folyamatnak. TL_VESZ.LOG a TextLib exporttal előállított csereállomány betöltésekor, a TL_VESZ.EXE működésekor, HM_VESZ.LOG pedig a HunMarc formátumú rekordok átvételekor, a HM_VESZ.EXE munkája nyomán keletkezik. A programok automatikusan hozzák létre a .LOG-okat, és az adatbázis mellé, tehát általában a \TEXTLIB könyvtárba helyezik. Fontos tudni, hogy az egymást követő betöltések nem tiszta lappal indulnak, hanem az új bejegyzések az egyszer korábban létrejött állományt bővítik új szövegrészekkel. A legkésőbbi importról szóló leírás tehát mindig a napló végén olvasható. A napló állományt természetesen nem muszáj őrizgetni, nyugodtan le szabad törölni, de csak ha már meggyőződtünk a betöltés sikeréről.

A TextLib csereállományok importja és a HunMarc formátumú rekordok betöltése egymásnak rokonai, így a következőkben együtt foglalkozunk a kettővel. Természetesen nem feledkezünk meg az eltérésekről, amennyiben említésre méltók.

Keressük meg tehát a TL_VESZ.LOG állományt a \TEXTLIB könyvtárban, és nézzünk bele egy szövegszerkesztővel (pl. EDIT a DOS-ban, Jegyzettömb vagy WordPad a Windowsban)! Íme a szöveg kezdete:

 1. ***** 2001-01-15 13:53 **************************************************
 2. C:\TEXTLIB\EXE\TL_VESZ.EXE 0.tcs /cc:\textlib\exe\lev_vesz.cfg /aigen
 3.
 4. TL_VESZ V1.76 - TextLib import     InfoKer 1995-97
 5.
 6.   Input:0.tcs   Log:TL_VESZ.LOG  Cfg:c:\textlib\exe\lev_vesz.cfg
 7.   Küldő: MKK / Magyar Közkönyvtár
 8.   Készítő:TL_KULD V1.30
 9.   Küldés ideje:2001-01-15 12:40  Rekordok:1432+4680+2233

A szöveget egy véletlenszerűen választott naplóból ollóztuk ki, az egyetlen változtatás az igazihoz képest a sorok megszámozása. A következő magyarázatokban ezekre a sorszámokra hivatkozunk.

Az első sorban az import időpontja látható, a 2. a parancssor, ami a műveletet indította. A programnév után írt kapcsolókról most nem szólunk, a TLDOC programmal olvasható dokumentáció TL_VESZ és PRGPARAM című fejezetéből minden fontos megtudható. A 4. sor legfontosabb eleme az import program verziószáma (V1.76). A telepítéskor és a felújításkor ügyelni kell arra, hogy a rendszerhez tartozó TL_VESZ.EXE és HM_VESZ.EXE is a helyére kerüljön. Ezt megkönnyíti, hogy az InfoKer honlapon a felújító készlet és a hozzátartozó programok ugyanazon a helyen találhatók meg.

A program futási körülményeit foglalja össze a 6. sor. "Input" a betöltendő állomány helye és neve, "Log" éppen a jelen írás tárgya, "Cfg" pedig az importot vezérlő szabályrendszer helye és neve. A HunMarc import naplójának bevezetője itt véget is ér, a 7, 8. és 9. sor csak a TextLib saját csereállományainak betöltésekor értelmezett. A 7. sor a csereállomány küldőjének adatbázis azonosítója és neve, az export folyamán a program olvassa ki a kiinduló adatbázisból.

Az adatbázis azonosító az importált rekordok azonosítójának részévé válik, segítségével a program felismeri az azonos forrásból származó rekordokat. Célszerű tehát az adatbázis azonosító értékét egyszeri kitöltés után változatlanul hagyni. És hogy a különböző forrásból származó rekordokat a program semmiképpen se tekinthesse azonosnak, az egymással rekordokat cserélő könyvtárak adatbázis azonosítói nem lehetnek egyformák. Erről a rendszer képtelen gondoskodni, ezt kizárólag szervezéssel lehet megoldani. A TextLibes könyvtárak számára kiosztható egyedi adatbázis azonosítók nyilvántartója jelenleg az InfoKer, export-import műveletekben az onnan kapható azonosítót érdemes használni. (A vonalkódos cimkék bevezető karaktersorozata is ez a számsor szokott lenni.)

A csereállományt készítő program neve olvasható a 8. sorban. A verziószám (V1.30) ebben az esetben lényegtelen, hiszen az import szöveg a progrmaváltozatoktól független és állandó szerkezetű. Nyugodtan fel szabad tehát használni egy ősrégi TL_KULD.EXE által létrehozott csereállományt. A 9. sor első fele az export időpontjáról tájékoztat. A "Rekordok" utáni három szám az exportált és az azokból hivatkozott rekordok, továbbá az azokban található almezők száma. A betöltés közben a képernyőre írodó futó sorszám a munka befejeződésekor a három szám összegét éri el.

A bevezető szövegrész után a naplóban egy lista következik. Ebben érkezési sorrendben a csereállomány összes rekordja megtalálható, mellette pedig egy leírás arról, hogy mi történt vele az import során. A történést két körülmény döntő mértékben befolyásolja, amelyekhez magyarázatot is illik mellékelni:

A fentiek ismeretében most már könnyedén értelmezhetők azok a néhány szavas megjegyzések, amelyek az import történéseit írják le. A szövegek a betöltés céljától és az összehasonlítás eredményétől függő műveletre utalnak, foglaljuk össze ezeket:

  Törlés Bevitel Módosítás
A megjegyzés, ha azonosak Töröltem
Törlés helyett módosult
Nem törölhető
NEM vittem beEgyeztetve
Ugyanez
A megjegyzés, ha különbözők nincs ilyen rekord Bevíve Bevíve

A táblázat elemei a napló egy-egy sorának kulcsszavai, de a sorok azoknál többet tartalmaznak. A kiegészítő részek állandók vagy gyakran ismétlődők, érdemes azokat is összefoglalni. Tekintsük mintának a következő sorokat (a sorszámok ismét csak a könnyebb eligazodást segítik):

 1.   MKKat3 : AZON: at4(DEMOat3)
 2.   MKKat2 : Azon(r1): at4(DEMOat3) Egyeztetve Módosult
 3.   MKKg283 : Azon(d1): g159412() Egyeztetve Módosult
 4.   MKKf23 : Azon(mj): f512() Egyeztetve Módosult
 5.   MKKb1965 : Hason(r1): b2(MKKb343) Bevíve: b7
 6.   MKKt1014 : Bevíve: t2045
 7.   MKKed11198 : nincs ilyen rekord
 8.   MKKt4 : NEM vittem be
 9.   MNB0324-5837 : Bevíve: d23
10.   MNB : Azon(r1): t2() Ugyanez
11.   MNB : Bevíve: e24
A sorok kezdete nagyon hasonló, csaknem mindenhol egy kibővített rekordazonosítót látunk, az úgynevezett importazonosítót vagy külső azonosítót. "MKK" és "MNB" a képzeletbeli könyvtár adatbázis azonosítója, innen kapjuk a csereállományokat. Mögötte az 1-2 betű és sorszám már az ismert rekordazonosító a küldő könyvtárban. A 9-11. sor HunMarc rekordok importjakor keletkezett, a rekordazonsító hiánya ezeknél megengedett. A hiány oka az, hogy a HunMarc rekordok többnyire bibliográfiai rekordok (közös adat, kötet adat, sorozat), az ezekből kiolvasott besorolási rekordoknak önálló azonosítója nincs. Az importazonosítót az érkező rekord magával hozza, ha beépül az adatbázisba. És ahogy korábban már szó volt róla, egy minden másnál biztosabb azonosító adatává válik a rekordnak.

Az 1-5. sorban az importazonosító után az összehasonlítás eredményére utaló szó áll (AZON, Azon, Hason), azt követheti egy rövid zárójeles kifejezés, majd annak a rekordnak a rekordazonosítója következik, amelyikkel az import program az érkező rekordot azonosnak (hasonlónak) találta. A rekordazonosítóról nincs mit mondani, a mögötte álló importazonosítóról - ha van - annál inkább. Akkor nem üres a zárójel, ha a fogadó adatbázisban talált rekord szintén importból érkezett, vagy egy korábbi betöltés módosította. Egy nagyon fontos kiegészítés kívánkozik ide: az a korábbi betöltés lehet az éppen most zajló is, annak egy korábbi szakasza. Az 1. és 2. sorban az érkező rekordot egy másik adatbázisból származóval (DEMO) találta azonosnak a betöltő program, az 5-ben pedig egy ugyanabbol - akár éppen most - érkezettel hasonlónak. A 3. és 4. sorban azonosnak mutatkozó rekordok saját rekordok, nincs importazonosítójuk. Még egy helyen bukkan fel a rekordazonosító a mintául választott sorokban, a "Bevíve" megjegyzés után. Ez most már az importban újonnan bekerült rekordé az 5. 6. 9. és 11. sorban.

Adósok maradtunk a rövid zárójeles kifejezés magyarázatával. Emlékezzünk, hogy az importot vezérlő szövegállományban azonosítás céljára több sorban tehetünk rendelkezéseket. Betöltéskor a program ezeket egymás után elemzi, de befejezi a vizsgálatot, ha megállapította az azonosságot. A zárójelben a .CFG állomány egyik azonosító sorának sorszáma olvasható, mégpedig azé, amelyik szerint az érkező és a bent levő rekord azonossága igaz. Mivel pedig a leírás vonatkozhat rekordtípusra (r) vagy adatfile-ra (d), a sorszám mellett ennek megfelelő betű áll.

A sokféle adat nem öncélúan szerepel a naplóban. A szöveg alapján pontosan nyomon követhetjük a csereállomány minden rekordjának sorsát. Válasszuk példának a korábbi felsorolásból az 5. sort.

 5.   MKKb1965 : Hason(r1): b2(MKKb343) Bevíve: b7
A kiinduló adatbázis b1965 azonosítójú rekordját az import program hasonlónak találta a fogadó adatbázis b2 azonosítójú rekordjával. A zárójelben álló MKKb343 szerint b2 vagy importból érkezett vagy az import módosította, hiszen MKKb343 a rekord importazonosítója lett. A hasonlóságot a betöltő program a .CFG állományban megadott szempontok közül az 1. alapján állapította meg, ezt (r1) mutatja. Végül az érkező rekord b7 azonosítóval bekerült újként a fogadó adatbázisba.

Az 1-11. felsorolás többi elemének értelmezése ezek után nem igényel külön magyarázatot, azok mind egyszerűbbek a példának választottnál. Van azonban pár apróság, amiről eddig nem szóltunk. Rögtön az 1. sorban ismeretlen a csupa nagybetűvel írt AZON.

 1.   MKKat3 : AZON: at4(DEMOat3)
Akkor látunk ilyet a naplóban, ha az azonosságot a program az importazonosító alapján állapította meg. Ez a sor tehát azt jelenti, hogy az MKK adatbázisból at3 azonosítóval érkező rekord már korábban betöltődött az adatbázisunkba. Akkor DEMO volt a küldő, onnan is at3 azonosítóval érkezett, és at4-gyel épült be hozzánk.
 4.   MKKf23 : Azon(mj): f512() Egyeztetve Módosult

Ebben a sorban a (mj) az ismeretlen elem. Jelentése rokon a szintén zárójelbe írt r1 vagy d2 jelzéssel, azt fejezi ki, hogy az összehasonlítás szempontjai közül melyik alapján találta azonosnak a program a rekordokat. Most a fogadó adatbázis egyik rekordjába beírt speciális megjegyzés miatt áll fenn az azonosság, vagyis itt az összehasonlítás szempontjait szándékosan mellékesnek tekintve mi nyilatkozunk két rekord azonosságáról. A napló bejegyzés tehát úgy jött létre, hogy a saját adatbázisunk f512-es rekordjának rendszer megjegyzés mezőjébe az import előtt az azonosság tervezett előidézése céljából beírtuk, hogy

#azonos: MKKf23

A 11 példa nem tartalmazta a törlésnél előforduló kulcsszavakat. Nézzük végig ezeket!

1.  MKKe5.2 : AZON: e2(MKKe5.2) Töröltem
2.  MKKar10 : AZON: ar3(MKKar10) Törlés helyett módosult
3.  MKKad1 : AZON: ad2.2(MKKad1) Nem törölhető

Mindhárom mintasor a küldő adatbázisból korábban érkezett rekord törlését írja le, ezt mutatja a nagybetűs AZON. Az 1. sor egy egyszerű rekord törlés, a 2. egy picivel összetettebb eset. Különböző forrásokat felhasználó egymást követő betöltések azonosnak minősíthetnek különböző adatbázisokból származó rekordokat. Ezek a rekordok viselik az összes kiinduló adatbázisból származó külső azonosítót, ezzel jelezve a több forrást, és a többszörös azonosságot. Az import program egy ilyen rekord törlésekor természetesen nem törli ki ténylegesen a rekordot, hanem csupán módosítja a rekordot. Kitörli belőle azt az importazonosítót, amelyik a most küldőként szereplő adatbázisból való származást tanúsítja. A 2. sor tehát azt jelenti, hogy az adatbázisunk ar3 azonosítójú rekordja a törlés következtében megmarad, de többé semmi nem mutatja az MKK adatbázissal volt kapcsolatát. A 3. sor egy sikertelen törlés bejegyzése, a rekordot a kapcsolatai miatt nem szabad kitörölni az adatbázisból. A törlési szándékot a program a rekord rendszer megjegyzés mezőjében kétféleképpen jelzi:

#!törlendő
#!megszünt
A szöveg attól függ, hogy mi volt a törlés oka:

A második eset megint magyarázatot követel. Tudnunk kell azt, hogy az adatbázisból kitörölt rekordok helyét az újonnan bevittek elfoglalják, és öröklik a régi rekordazonosítóját. De hogy összekeverni mégse lehessen őket, egy pici változtatással: egy kiegészítő sorszám mutatja, hogy ugyanazon a helyen hányadikként található most a rekord. A törölt helyére kerülő új .2 kiegészítést kap, majd az annak a helyére kerülő .3-at, és így tovább. A mi adatbázisunk csak az importált rekordokon keresztül értesül a kiinduló adatbázis változásairól. Természetesen értelmetlen lenne előírni, hogy minden változást követni kell. Így lehetséges tehát, hogy a fogadó adatbázis egy rekord törléséről nem a rekord törlés tényéből, hanem a helyére került új rekord létéből értesül. A "megszünt" megjegyzés éppen az ilyen esetet jelzi.

Ez a jelenség bevitel vagy módosítás céljából folyó import közben is előfordulhat. Az esetet leíró napló bejegyzés a következő:

MKKt158.2 : Bevíve: t175
  Megszünt: t31 (MKKt158) Töröltem

A példában t158.2 puszta léte jelzi, hogy t158 már nem létezhet. Így - bár a betöltés célja nem a törlés - az új rekord bevitele után a program mellékesen kitörli a megszünt rekordot.

A napló sorai az érkező rekordok mindegyikéről mondanak valamit, és most már minden sort tudunk értelmezni. Ennek alapján kell eldönteni, hogy az import program a szándékainknak megfelelően cselekszik-e. A két leggyakoribb hiba, hogy a betöltés azonosnak tart két rekordot, ami pedig nem az, vagy éppen fordítva, különbözőnek két azonosat. A hibás végeredményt a saját adatbázisunkban látjuk, a hibához vezető utat pedig a napló rögzíti. De mit keressünk a naplóban, ha a hiba nyomára akarunk bukkanni?

Ezeket a hibákat a program képtelen felismerni, hiszen az összehasonlítás mechanikus, sem az azonosság, sem pedig a különbözőség ténye nem minősít. A naplóban olvasható bejegyzések ilyenkor is a már megismert mintákat követik, nekünk kell felismerni, hogy egy szokásos tartalmú sor egyes esetekben hibát jelez.

Következő példánkban az érkező és a már bent levő rekord egyesül, pedig nem ezt szeretnénk. Amit látunk, hogy a váratlan és indokolatlan azonosság következtében eltünnek rekordok az import műveletében. Tudnunk kell, hogy mi hiányzik, mégpedig az azonosítóját. A kiinduló adatbázisban vagy ha az nincsen, akkor a csereállományban keresve nem nehéz megtalálni. Ugyanez az azonosító előfordul a naplóban is, a sor elején, az érkező rekord azonosítójaként. Íme:

 3.   MKKg283 : Azon(d1): g159412() Egyeztetve Módosult
A szövegben megtaláljuk, hogy melyik összehasonlítási szempont (d1, tehát az első) eredményezi az azonosságot, majd rögtön utána az érkezőt elnyelő saját rekord azonosítóját. Minden bizonnyal a .CFG állomány "f" jelű, tehát alkotó rekordokra vonatkozó első azonosító sorát kell módosítanunk, ha a g283-as rekord indokolatlanul egyesül a g159412-vel.

Kevesebb információt tartalmaz a napló a másik gyakori hibáról, amikor a rekordok a várt azonosság helyett különbözőnek bizonyulnak:

 6.   MKKt1014 : Bevíve: t2045

Ekkor is a .CFG-t érdemes vizsgálni, az összehasonlítás pontatlansága vezetett a duplázódáshoz. Két rekord azonosságára számítottunk, amelyekből a napló csak az érkezőről, t1014-ről tesz említést. A másikról, a mi adatbázisunk ugyanilyen rekordjáról a program nem tud, hiszen ha tudna, nem vitte volna be az érkezőt újként t2045-tel. Az azonosságot mi várjuk el, nekünk kell tudni, hogy mivel kellene azonosnak lenni az importált rekordnak. A hibát is valószínűleg a duplázódás tényéből vettük észre, abból, hogy egy expand böngészése közben egyszer csak kettő előfordulását találtuk valaminek, amiből pedig egy is elég.

Keressük meg tehát a két rekordot, vizsgáljuk meg az azonosságukat, és ellenőrizzük a .CFG állomány azonosító sorait! A rekordok tényleges azonossága esetén csak az azonosító sorok pontatlansága okozhatta a duplázódást.

Illetve...

Ismert és sajnálatos jelenség a rekordok sokszorozódása az import következtében. Írtunk erről a 4. hírlevél "A besorolási adatok egységesítése" című fejezetében.

Található még a naplóban egypár bejegyzés, ami az eddigi ismertetésből kimaradt. Ilyen a

  $at2 : kihagyva

sor. Ahogy korábban már említettük, a .CFG állománynak minden importálandó adatfile-ról és/vagy rekordtípusról leírást kell tartalmaznia. A $at2 rekordot azért hagyta ki a betöltő program, mert az "at" (projekció) rekordokról nem rendelkeztünk a .CFG-ben. Szándékos is lehet a kihagyás, ilyen módon lehet szűrni a csereállományt.

Találhatók hibaüzenetek is a naplóban. Kezdjük azzal, amelyik hiba is, meg nem is:

  MKKb140 :
!!   1.HIBA(333): Sok hasonló rekord /   !!   Bevive: b159

Ismét vissza kell nyúlnunk a .CFG állományhoz. Az érkező és meglévő rekordok összehasonlításához azonosító és hasonlító sorokat is megadhatunk. Utóbbiak útján értesülünk arról, ha a fogadó adatbázisban az érkezőhöz hasonló rekord(ok) található(k). Az import program ugyanis a hasonlító feltételek szerint is keres az adatbázisunkban, és listát készít a megfelelő rekordokról. E lista bősége figyelmeztethet az adatbázisunkban esetleg fölöslegesen fellelhető rekordokra, a duplázódásra.

Általában mellékesnek tekinthető az

!!   1.HIBA(338): Üres mező / 053 (61349.sor)  !!
MKKb1450 : Bevíve: b150190

üzenet a naplóban. Az üres mezőt tartalmazó rekord betöltése minden bizonnyal rendben lezajlott, a figyelmeztetés inkább a küldő adatbázis vagy az export program hibáját mutatja. Ha a küldő is mi vagyunk, akkor megéri megkeresni a b1450 azonosítójú rekordot, és annak a 053-as mezőjében, a szerzőségi közlésben a véletlenül beírt magában álló szóközt kitörölni. Amennyiben a megtalált mező mégsem üres, akkor az export program hibája eredményezte az üzenetet, a csereállomány létrtehozója tud esetleg tenni ellene.

A következő napló bejegyzés a 6. mintasornak közeli, de elfajzott rokona:

  MKKb20478 :
      19. HIBA: Indexelés(84)/b168952/KULSOAZON/MNB234452b Bevíve: b168952

MKKb20478 új rekordként b168952 azonosítóval épült be az adatbázisunkba. De a szövegbe egy hibaüzenet ékelődött be: b168952 tárolása közben a KULSOAZON indexállományba nem sikerült beilleszteni az MNB234452b értékű kulcsot. A b20478 vagy importból érkezett, vagy módosította már egy betöltés, hiszen van importazonosítója, az előbb említett MNB234452b. De ezzel sajnos baj van, van már ugyanis egy rekord az adatbázisunkban, amelyikben előfordul pontosan ugyanez az importazonosító, márpedig a KULSOAZON index nem engedi meg, hogy ugyanaz a kulcs kétszer is belekerüljön.

Összefoglalva: egy rekordot kétszer importáltunk, először közvetlenül a forrásból MNB234452b azonosítóval, majd MKK közvetítésével b20478 azonosítóval. A hiba abból származik, hogy a .CFG-ben leírt azonosítási szempontok alapján az import program a nyilvánvalóan azonos rekordokat különbözőnek ítélte. Ez a .CFG hibája, az azonosító sorok módosításával orvosolható.

Emlékezzünk vissza egy korábbi megjegyzésre: egy rekord önmagával minden körülmények között azonos. Ez a szabály most mégsem érvényesült, mert a rekord másodszorra MKK-n keresztül érkezett, az onnan kapott, nem pedig az eredeti importazonosítóval. A .CFG javításával sem egységesülnek az importazonosítók, viszont az azonosítás eredményes lesz.

Foglalkozzunk azokkal az esetekkel is, amikor az import valami hiba miatt el sem indul. A csereállomány vagy a vezérlő állomány hiánya miatt a

  File megnyitási hiba: 0.tcs
vagy a
  File megnyitási hiba: ..\TL_VESZ.CFG
hibaüzenetet kapjuk. A magyarázat kézenfekvő: a fájl a megadott néven és/vagy elérési úton nem található. Rosszul adtuk meg, vagy nem a tervezett helyre másoltuk őket. Könnyen előforduló, de nehezen megfejthető a
!!  1.HIBA (336): Más csere file-t adott meg / 0.t03  !!
üzenet. A "/" utáni név az, amit a parancssorban megadtunk betöltendő szövegállományként, a program viszont valami mást várt. A tény, hogy egyáltalán várt valamit, vezet el a megoldáshoz. Az import programok általában tetszőleges nevű cserefájlt betöltenek, kivéve ha egynek a feldolgozását szándékosan félbeszakítottuk. Ilyenkor ugyanis a program a leállított betöltés folytatására számít, és hibának tekinti egy új import elkezdését. Így most már adott a kivezető út is:

TL_VESZ.BRK őrzi ugyanis a folytatáshoz szükséges információkat, az akadályozza meg egy új import végrehajtását. Még egy megjegyzés a hibához, illetve általánosabban a megszakított betöltés folytatásához: még belegondolni is rettenetes, hogy mekkora kalamajkát okozhat, ha a félbehagyott importot a csereállománynak egy azonos nevű másikra történő kicserélése után folytatjuk.

A TextLib export program a kiküldött rekordokból szükség szerint több csereállományt hoz létre. Egyetlen nagyméretű állományt ugyanis nem könnyű feladat számítógépek között mozgatni, ha a méret meghaladja a hajlékonylemezek szokásos kapacitását. Az egyszerűsítés érdekében a program olyan csereállományokat hoz létre, amelyek ráférnek a lemezre, és annyit, amennyit kell. A szállítás így most már könnyedén megoldható, csupán a sorrendre kell ügyelni betöltéskor. A nevekbe írt sorszám segít ebben, de ha mégis eltévesztjük, az alábbihoz hasonló hibaüzenetet kapunk, és a művelet leáll:

  Nem volt importálva a MKKw2724 rekord (ami a 0.t02 file-ban van)

A hiba ebben az esetben tehát az, hogy megkiséreltük betölteni a "0.t03" nevű csereállományt a "0.t02" nevű előtt.

A következőkben egy teljesnek gondolt rövid összefoglalót adunk azokról a hibákról, amelyek a vezérlő állomány (általában TL_VESZ.CFG vagy HM_VESZ.CFG) elrontott tartalma miatt teszik lehetetlenné az importot:

!!   1.HIBA (313): Rossz leíró file / c:\textlib\exe\tl_vesz.cfg (1. sor)  !!
!!   1.HIBA (318): Rossz 'Kodkeszlet:' sor / CVI (5. sor)  !!
!!   1.HIBA (319): Rossz 'Cel:' sor / N (6. sor)  !!
!!   1.HIBA (320): Rossz mező / REZSJELZES (11. sor)  !!
!!   1.HIBA (330): Túl sok azonosító mező (max 8) / (9. sor)  !!
!!   1.HIBA (331): Túl sok 'Azonosito:' sor (max 4) / (14. sor)  !!
!!   1.HIBA (332): Nem adott meg indexelt mezőt / (11. sor)  !!
!!   1.HIBA (334): Másodszori definíció / (20. sor)  !!

Közös vonásuk, hogy az üzenet végén a zárójelben a program kiírja a hiba helyét. A 313-as, 318-as, 319-es, 330-as és 331-es hiba kizárásának módja kiolvasható a TLDOC.EXE programmal olvasható dokumentáció IMPLEIR.TXT nevű szövegéből. A 320-as és 332-es megoldása az adatbázis leírásban keresendő, a 334-es egy egyszerű sajtóhiba: egy adatfile vagy rekordtípus kezelésére utasító szövegszakasz kétszer szerepel a .CFG-ben.

A címben feltett kérdésre válaszolva kijelenthetjük tehát, hogy TL_VESZ.LOG illetve a HM_VESZ.LOG az import lefolyásának és minőségének ellenőrzésére jó. Egy betöltés után két helyen érdemes vizsgálódni: az adatbázisban és a naplóban. A duplázódásokat legkönnyebben a soféle expand böngészésekor lehet észrevenni a kulcsok számának megnövekedéséből. A rekordok eltünésének a naplóban marad nyoma, az "Egyeztetve" megjegyzés mindig két rekord egyesülését jelzi. A javítás helye mindkét esetben az importot vezérlő szövegállomány, a TL_VESZ.CFG vagy a HM_VESZ.CFG, ha indokolatlan volt a rekordok duplázódása illetve a egyesülése.


Hírek a TextLib levelező listáról

A listán korábban megjelent leveleket ékezetesítettük a könnyebb olvashatóság érdekében, a tartalmuk változatlan. Két témát választottunk:

Telematikai fejlesztés

2001. január 9.

T. List!
Itt az új évezred, az idő szalad, el kellene töprengenünk azon, hogy mire
költsük a tavalyi telematikai pályázaton nyert 1 mFt-ot.

Az gondolom világos, hogy az eredeti pályázatban megcélzott fejlesztés (5 mFt)
ebből nem valósítható meg, a minisztériumi szerződésben szereplő "TextLib
fejlesztése" kitétel azonban - talán - megengedi, hogy más, mindannyiunk
hasznára váló fejlesztés(ek)re költsük a pénzt.

Egy komoly javaslatom van (még nincs beárazva), s bízom abban, hogy Nektek is
lesznek igényeitek.

A javaslat:
A Könyvtáros Egyesület, OSZK stb. segítségével Ungváry Rudolf elkészítette a
Köztauruszt és Taxauruszt közművelődési könyvtárak számára, s SRLIB-es
könyvtárak ezt állítólag nagy sikerrel használják. (A tezaurusz szabadon
letölthető.)

Arra gondoltam, hogy az InfoKerrel kellene csináltatni (esetleg a TO mező
helyett) egy új, az MSZ 3418-87 (Magyar nyelvű információkereső tezauruszok
szerkezete, részei és formái) szabvány szerint készült deszkriptorcikkek
kezelésére alkalmas mezőt, így programunkban négy tárgyszavazási lehetőség állna
rendelkezésünkre:
- 'Deszkriptora' - "mondjuk" szabad tárgyszavazásra, a könyvtár saját
tárgyszórendszerének (ha van) kezelésére;
- 'Zenei' és 'Helyismereti' a megfelelő gyűjteményrészek tartalmi feltárására;
- 'Tezaurusz' (munkanév!) az Ungváry és csapata által fejlesztett és
karbantartott tartalmi feltáró eszköz kezelésére.

Így a TextLibes katalógusainkban meglevő dokumentumok egységes, természetes
nyelvű tartalmi feltáró eszközzel is kereshetők lennének.

Persze ez csak egy ötlet. Vélemények (és árajánlatok) kellenének, ha lehet
mielőbb.

Üdv:
Takáts Béla
könyvtáros
Jász-Nagykun-Szolnok Megyei Verseghy Ferenc Könyvtár
2001. január 16.

T. List!
Noszogatásom óta két - a fejlesztéssel alapvetően egyetértő - levelet kaptam.
Most váltottam e-mailt Ungváry Rudolffal. Közlése szerint rövidesen elérhető,
szabadon letölthető lesz a tezaurusz HUNMARC formátumban is, azaz iszonyatos
munkától szabadulhatunk meg, ha felvállaljuk a fejlesztést ilyen irányba.

Nos. Belevágjunk?

Üdvözlettel:
Takáts Béla
könyvtáros
Jász-Nagykun-Szolnok Megyei Verseghy Ferenc Könyvtár
2001. január 16.

Szóval a kérdés ez:
1 millióért vállajuk-e, hogy csinálunk még egy tárgyszó rendszert (az
általad említett, és általam még eddig elkerült szabványnak remélhetőleg
megfelelőt), importáljuk a tezaurusz rekordokat, és mindenkinek
elérhetővé tesszük mindkettőt.

Ha ez most tényleg komoly kérdés, akkor komolyan utána kell néznünk.
Esetleg a szabványt is beszerezzük. Az interneten nincs fenn, nem tudod?

Gräff Zoltán (InfoKer)
2001. január 16.

Tisztelt TextLibesek!

Takáts Bélának a tárgyszórendszerre vonatkozó ötletét semmiképpen sem
hiúsíthatja meg a HunMarc leírás hiánya: a HunMarc 1999-es módosításának
eredményeként mindenféle (tehát már nemcsak a könyv) dokumentumtípus leírható,
és a besorolási rekordoknak is van adatcsere formátuma.

Külön exportálható és importálható:
- személy
- testület
- rendezvény
- cím
- tárgyszó
- földrajzi név

Üdvözlettel:
                Thék Gyorgy (InfoKer)
2001. január 16.

Hát ez a kérdés. Nekem mindenképpen az egyesületi tagok egyetértésével kell
döntenem, elvégre közös pályázatról, közös pénzről van szó. Semmiképpen nem
akarom, hogy bárki azt mondhassa: a szolnokiak saját maguknak fejlesztetik a
TextLibet. (Volt már ilyen... :-))

Szerintem a Monok és az Ungváry garancia arra, hogy ebből lesz valami (mármint
a tezaurusz továbbéléséből és karbantartásából), de jó lenne, ha kapnék egy pár
"EGYETÉRTÜNK, CSINÁLJÁTOK" tartalmú levelet.

Fénymásolatban a holnapi postával megy (MSZ 3418-87). Írtam az Ungvárynak, hogy
a deszkriptorcikkből HUNMARC rekordokat csinaló adatbázis leírását, előzetes
rendszertervet, ill. azt, ami erről rendelkezésre áll küldje már el. Ha jön,
megy.

Üdv:
Takáts Béla
könyvtáros
Jász-Nagykun-Szolnok Megyei Verseghy Ferenc Könyvtár
2001. január 16.

Szerintem vágjunk bele! Általános magyar tárgyszójegyzék feltehetően sohasem
lesz. Ez meg már megvan és használható.

Komlósi József (Vörösmarty Mihály Megyei Könyvtár - Székesfehérvár)
2001. január 16.

Vágjunk hát, jobb ötletem nincsen...

Gaál Sándor
Tiszafüred, Városi Könyvtár
2001. január 24.

T. List!
Mivel jobb ötlete senkinek sem volt és kaptam egy pár támogató e-mailt, ezúton
hivatalosan felkérem az InfoKer Számítástechnika-alkalmazási Szövetkezetet, hogy
készítsen árajánlatot:

1. Az MSZ 3418-87 (Magyar nyelvű információkereső tezauruszok szerkezete részei
és formái) előírásainak megfelelő mező elkészítésére, ill. ennek a "Köztaurusz
alkalmazási és karbantartási szabályzatával" való összefésülésére (jelenlegi,
1.0 változat).

2. A "Köztaurusz" deszkriptorcikkeinek HUNMARC (vagy ahhoz hasonló :-))
formátumban való megjelenése után ezen rekordok TextLibbe töltésére (az első,
csereformátumban megjelenő verzióra vonatkozik ez, a változásokat már a
könyvtárak egyénileg vezetik, vagy valahogy megegyezünk).

3. A fenti fejlesztések átadására valamennyi könyvtár számára, aki
regisztráltatja magát a TextLib Egyesület tagjai közé.

Az InfoKer árajánlatat, ill. az ez alapján kötendő szerződés szövegét a TextLib
Egyesület honlapján közzéteszem, erről a listát értesítem.

A fejlesztés tesztelésében, az esetleges terminológiai meg nem értések
kezelésében kérném a t. programhasználók küzreműködését.


Üdvözlettel:
Takáts Béla
könyvtáros
Jász-Nagykun-Szolnok Megyei Verseghy Ferenc Könyvtár
2001. január 25.

Két dolgot vetnék fel:

1. A TextLibben a jelenlegi Tezaurusz szerkezete az érvényes magyar szabvány
szerint készült. Ebből a fejlesztés során négy lett a rendszerbe definiálva,
kérdés elfogyott-e mind a négy? Változott-e a szabvány?

2. A teljes HUNMARC (minden dokumentumtípusra és az authority rekordokra:
személyek nevei, testületi nevek, földrajzi nevek, rendezvények nevei, címek,
tárgyszavak) import programot a FSZEK külön szerződés keretében kifejleszttette
már az Infokerrel 1999 folyamán. A program működik, az apróbb hibák javítása
jelenleg folyik.

Nem kétséges, hogy a már kifejlesztett programokat is szükséges adaptálni egy
cél alkalmazáshoz. Ez még egy "szabványos" HUNMARC állomány és egy hasonóan
"szabványos" HUNMARC import program esetében is szinte törvényszerű lehet, éppen
az idézőjeles szabványosság miatt.

Nagy Anna
FSZEK
2001. február 13.

Tisztelt TextLibesek!

Bocsánatot kérek, hogy csak ilyen későn válaszolok Nagy Anna levélere,
de talán aktuális még a dolog.

A szabványosság sajnos nem igaz. Jó a tezaurusz, de nem szabványos. Ez a
meg nem felelés is a szépemlékű bizottságos idők egyik maradványa.

Az adatszerkezetben található negyedik tezaurusz valóban szabad még.

Szerintem a fejlesztés nem vonatkozott az önálló besorolási rekordok
importjára. Az árajánlatunkban a következő szöveg szerepelt:
-------------------------
A HunMarc formátumú adatcserét végző import program módosítása az OSZK 1999.
tavaszán kibocsátott ajánlásában rögzített dokumentumtípusok és adatszerkezet
kezelése érdekében.
-------------------------
Ebben a szövegben nincs szó besorolási rekordokról, csak a HunMarc számára új
dokumentumtípusokról (audiovizuális, térkép, kotta stb.), és a már ismertek
(könyv és időszaki) szerkezetében történt változásról. A változás főként a
példány adatok beépülését jelenti.

A szöveg értelmezésétől függetlenül tény, hogy nem készült el a besorolási
rekordok importja, és persze a tezauruszé sem. A hiány miatt senki nem
reklamált. Az már csak egy apró gonosz kiegészítés, hogy akkor is csak a FSZEK-é
lenne a program, és nem a TextLib Egyesületé.

Üdvözlettel:
       Thék György
         InfoKer

Még mindig Realtek 8029

Ez a fránya 8029-es már többször is kapott apró, de egyáltalán nem mellékes szerepet a levelező listán és a hírlevelekben (3, 5, és 6. szám) is. Eddig nem volt jobb javaslatunk a Windows melletti használatra egy nagyon rossznál: tessék újat venni helyette!

Most két jó megoldás is született, hála Lajkó Csabának (Városi Könyvtár - Székesfehérvár) és Szűts Ferencnek (Jász-Nagykun-Szolnok Megyei Verseghy Ferenc Könyvtár - Szolnok). Ezúttal egy-két levelet szándékosan kihagyunk a témában írottak közül, hogy jobban kirajzolódjon a célhoz vezető út.

2001. január 19.

T List!

A lista sokatpróbált tagjainak a segítségét kérem.
Új számítógépen Textlib munkaállomást telepítenék.
Op rendszer Win98 SE  - hálózati kártya: SMC 1208BT
DOS alatt a kapcsolat rendben működik, de Windowsban az IPX driverrel
(vagy a beállításával) valami gond lehet. A munkaállomás ugyan
megtalálja a szervert, a szerver ablakban megjelenik a Bejelentkezés
(még senki) szöveg, de a munkaállomás képernyője megáll közvetlenül a
bejelentkező képernyő előtt (nagy kékség, valamint a nem funkcionáló
HELP es KILÉPÉS menüpontok látszódnak)... és lefagyás. A szokásos
beállításokon természetesen túl vagyok. Volt valakinek hasonló
tapasztalata, esetleg hasonló kártyája?

Más:
Korábban elterjedt, hogy a Realtek 8029-es hálózati kártyával nem
működik Windows 98 alatt a Textlib. Nálam ezekkel a kártyatípusokkal
nem volt ilyen gond.

Minden segítséget előre is köszönök

Preysing Frigyes
Kölcsey Ferenc Városi Könyvtár
Dunakeszi
2001. január 19.

A jelentkezett hiba kifejezetten hasonlít a Realtek 8029 kártyák hibájához.
Ha nem egyedi hibáról van szó, azaz a kártya hibás, akkor egy másik típussal
kellene próbálkozni! Segíthet még esetleg a frame értékét 802.2-re állítani.

Üdvözlettel:

Szűts Ferenc
Jász-Nagykun-Szolnok Megyei Verseghy Ferenc Könyvtár
2001. január 19.

Éppen ez az érdekes. Itt egy SMC-ről van szó, igaz csak OEM..
Ez már a második kártya, az előző egy Realtek volt.
Talán újra kellene installálni a Windowst.

Azért köszönöm.

Preysing Frigyes
Kölcsey Ferenc Városi Könyvtár
Dunakeszi
2001. január 22.

Azért ez talán ágyúval verébre lenne.
Ha DOS-ból jól megy a kártya, akkor a windows beállításokban keresendő
a gond. Biztos, hogy az ethernet frame type az IPX protokollnál FIX-en be
van állítva, és minden gépen ugyanarra?

Gräff Zoltán (InfoKer)
2001. január 23.

Üdv!

Én Realtek kártyával szenvedtem hasonló módon Win98 SE op. rendszerrel. A
megoldás végül is az lett hosszú szenvedés után, hogy eltávolítottam az SE
által feltelepített drivert, majd a Win98-as (nem SE!) drivert tettem fel.
Utána már tökéletesen működött a dolog. Remélem tudtam vmit segíteni.

Üdvozlettel:
Lajkó Csaba
rendszergazda
Városi Könyvtár, Székesfehérvár
2001. január 23.

Nekem jó tapasztalataim vannak a REALTEK 8139-es kártyák drivereinek
használatával a 8029-es kártyákhoz. Küldöm csatolva ezt a driver lemezt.
Próbáljátok ki, kíváncsi vagyok, hogy mi a tapasztalatotok.

Üdvözlettel:

Szűts Ferenc
Jász-Nagykun-Szolnok Megyei Verseghy Ferenc Könyvtár
2001. január 23.

T. Lista!

Talán volt aki követte az SMC hálókártya beállításával kapcsolatos levelezést a
listán. A megoldást végül a Lajkó Csaba által leírt javaslat jelentette. Azt
hiszem máshol, más esetben is hasznos információt jelent.

Mindenkinek köszönöm a probléma megoldásához nyújtott segítséget, természetesen
külön köszönetem Lajkó Csabának a frappáns megoldásért. És persze ne
feledkezzunk meg a Microsoft szoftverfejlesztőiről sem, akik nélkül ez a
probléma létre sem jöhetett volna.

Preysing Frigyes
Kölcsey Ferenc Városi Könyvtár
Dunakeszi

Újdonságok a programban

Egyszerűsített érkeztetés

A programrész az újonnan beszerzett példányok állományba vételére alkalmas. A művelet éppen olyan egyszerű, mint a példány bevitel, viszont számos előnye van ahhoz képest:

Ezt a TextLib kiegészítést azoknak a könyvtáraknak ajánljuk, amelyek:

A kiegészítés nem része a TextLibnek, külön lehet megvásárolni a rendszer felhasználóinak számához illeszkedő változatot:

Felhasználók száma Ár (+ 25% áfa)
1 5 500.-
5 9 000.-
10 17 000.-
25 28 000.-
50 45 000.-

Újdonságok keresése

A programrész dokumentumokat keres egy sajátságos módon: a könyvtárba érkezett újdonságokat találja meg. A műveletben természetesen szabályozható a dátum, amelytől kezdve újnak ítéljük a dokumentumokat. Ezen kívül két körülmény határozza meg a működést:

A kiegészítés nem része a TextLibnek, külön lehet megvásárolni a rendszer felhasználóinak számához illeszkedő változatot:

Felhasználók száma Ár (+ 25% áfa)
1 3.000
5 4.500
10 8.500
25 14.000
50 22.000

Egyéb újdonságok


Vissza: Hírlevelek TextLib honlap InfoKer honlap