[Textlib] Mezőcsere
Thék György
thekgy at infoker.hu
2009. Május. 22., P, 17:20:36 CEST
Kedves Károly!
> Sziasztok, köszönöm, ezzel megvolnánk - megcsinálta.
Ez jó hír!
> Most akkor azt szeretném kérdezni, hogy HONNAN KELLETT VOLNA TUDNOM
> ezt az 50-et.
A honlapunkon a TextLib HTML dokumetációnak a DBSTRUCT programmal
foglalkozó elég rövid leírásában a 'Rekordtípusok egyenként' cím
mögötti részéből.
Közvetlenül leírva a dokumentációban természetesen ilyen nincs. Az
adatbázis szerkezetének logikájából viszont következik, hogy a 68 nem
lehet jó. A 68 a raktár adatfájljának a sorszáma, ami persze nem
jelenti azt, hogy nem lehet ugyanakkor a példányban a raktár mező
sorszáma is. Lehetne, ha kizárhatnánk, hogy a példányban két raktár
mező lehessen. Nincs is, tehát a példány rendben van. A példányban
viszont van két kötet mező - egyrészt a példány kötete, másrészt a
volt kötete, selejtezés után -, azoknak biztosan nem lehet
azonos a sorszáma. Másutt is vannak többes hivatkozások.
> DBSTRUCT V1.66 (TextLib adatbázis szerkezet) - InfoKer
> 68. adatfile: RAKTAR --> 69.rek.tipus: RAKTAR
> Fômezôi: NEVE
> 48. NEVE(str)
> Index:RAKTARNEV(97), default
> 49. RNEV(str)
> 50. CIM(str)
> Amit fönt látunk: 50. CIM - nos, ez pontosan ugyanilyen. Ki hinné,
> hogy a semmitmondó CIM szó lesz a megoldás, és ez a raktár neve?!
> Különösen akkor, ha ott van mellette a NEVE mező is?!
Ez itt tévedés. A raktár rekordban a mezőknek nincs köze a példány
raktárához. Ha a példány raktárát kell módosítani, akkor a példány
raktár mezője az érdekes, a raktárnak egyetlen egy mezője sem. Tehát
ez az 50 nem az az 50. Itt az 50 a raktár címét jelenti, utca,
házszám. A példányban az 50 pedig a példány raktárát, ami mögött egy
komplett 68-as rekord rejtőzik, amit az egyszerűség kedvéért egy
rekordazonsító (u123456) helyettesít a raktár rekord részletei nélkül.
> Ez azt mondta, hogy "!!! Hiba: nincs adatbázis szerkezet (DBDESCR)"
Nem emlékszünk rá, és csak nagyon nagy befektetéssel tudjuk
kideríteni, hogy abban a verzióban mi okozhatta a hibát. Szerencsére
egy új ndx_lst működik az 1.62.04-gyel.
> Amúgy egy checkbox a felületen sokkal többet sugallna ebből, mint a
> Rendszergazdai tudnivalók alsó harmadában egy bajuszka...
Igaz.
> Vagyis az egy db. csonkolás jel nem feldi le az üres mezőt?!? Ez
> remélem, csak félreértés. Ha így lenne, nagy baj lenne, mert akkor
> nem lehetne megfogalmazni azt, hogy "MINDEN". Azért ugye, ez baj
> lenne?
Azért van így, mert az üres mezőt körülményes keresni még akkor is, ha
van rá index. (Keressük a cím nélküli könyveket.) Ha nincs index, még
nehezebb. Kényelmesebb tehát a mezőcserét kettéválasztani, ha létező
probléma, hogy másra kell cserélni a bárhogyan vagy pontosan
meghatározott értékkel kitöltött mezőt, mint az üreset.
Üdv: Thék
További információk a(z) Textlib levelezőlistáról