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.
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!
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:
Az importot vezérlő szövegben (általában TL_VESZ.CFG vagy HM_VESZ.CFG) háromféleképpen rendelkezhetünk a betöltés céljáról:
Mindhárom esetben fontos alapelv, hogy az érkező és a már bent levő rekordok azonosságát vizsgálni kell, ezt pedig az import program természetesen meg is teszi. Az összehasonlítás eredményétől függ a művelet, a változatokat a következő táblázat foglalja össze:
| Törlés | Bevitel | Módosítás | |
| A művelet, ha azonosak | törlés | -semmi- | módosítás |
| A művelet, ha különbözők | -semmi- | bevitel | bevitel |
Látható, hogy az importot alapvetően befolyásolni képes a megjelölt cél, az esetek túlnyomó részében mégsem nehéz a választás, hiszen a módosítás a leggyakoribb feladat. A program alapértelmezett működésmódja is ez, a cél megadásának hiányában módosítást végez.
Ebben a szakaszban maradt még egy nyitott kérdés, a rekordok azonossága. Mikor azonos két rekord? Egy eset kivételével mi rendelkezhetünk arról, hogy az import program mely rekordokat tekintsen azonosnak, erről szól éppen a következő pont.
A vezérlő állományban aprólékosan szabályozhatjuk, hogy mit vizsgáljon az import program, amikor két rekordot összehasonlít. A részletek a TLDOC.EXE programmal olvasható dokumentáció IMPLEIR.TXT című fejezetéből derülnek ki, most a lényegről csak annyit állapítsunk meg, hogy szinte tetszőleges mezőket jelölhetünk ki, azoknak a tartalmát veti egybe a program páronként az érkező és már meglévő rekordokban.
Van azonban egy fontos szabály az összehasonlításban, ami felülbírálja az eddig leírtakat: egy rekord önmagával minden körülmények között azonos. Egy forrásként használt adatbázisból - lehet az a szomszéd könyvtár vagy az Országos Széchényi Könyvtár rendszeres szolgáltatása - többször is megkaphatjuk ugyanazt a rekordot, hiszen minden jelentős változtatás után újra kiküldi a szolgáltató. A korábban már említett adatbázis azonosító és a rekordazonosító együttesen egyértelműen azonosítja a rekordot, ilyenkor tehát a .CFG-ben tett rendelkezéstől függetlenül az érkező rekord azonos saját maga korábbi változatával.
Összefoglalva: két rekord azonos, ha egyetlen rekord két adatbázisban előforduló két változata, vagy ha az összehasonlításra kijelölt mezőinek a tartalma azonos.
Végezetül ide tartozik az is, hogy az összehasonlításból is és a feldolgozásból is kimaradnak azok a rekordok, amelyekről a .CFG állományban semmiféle rendelkezés nincs. A program az ilyeneket kihagyja, mert a tennivalót magától ki nem találhatja.
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 be | Egyeztetve 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: e24A 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: b7A 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üntA 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ódosultA 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.tcsvagy a
File megnyitási hiba: ..\TL_VESZ.CFGhibaü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.
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:
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
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
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.- |
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 |
REINDEX TL_EGYEBparancs végrehajtása után válnak kereshetővé.
REINDEX TL_MUNKAparancs után használható.
Egyéb elérhetőség:
Internet: http://www.konyvtar.hu/doc/egri_csillagok.htm
Sőt, ez a mező a webes felületen is megjelenik, ahol link lesz belőle, és
mindjárt rá is lehet kattintani.
Vissza: Hírlevelek TextLib honlap InfoKer honlap