btbtx kérdés(ek)

Clipper, CCC

a helyzet:

egy adott bt tábla, egy vagy több oszlop nevét meg akarom változtatni.
a tstru konvertálja az adatokat,az oszlop új néven jelenik meg, de üresen.

tview :

azon nev
---------------------------
1 elso
2 masodik
3 nemindegy

az adat konvertálás után

id nev
----------------------
0 elso
0 masodik
0 nemindegy

az első oszlop primáris kulcsnak szánva.
a kérdésem:
meg lehet -e oldani külön konvertálóprogram írása nélkül?

  • 5223 megtekintés

( Wintermute | 2007. 02. 08., cs – 18:03 )

Én azt csinálnám, még ha nem is triviális, hogy a CCC-Winter csomagban lévő ccc3winterdb könyvtárral kiexportálnám CSV-be, átírnám a CVS-ben a header-t, megváltoztatnám a táblát, vagy újat csinálnék, és ugyanazzal a könyvtárral beimportálnám.

w

"mik a tapasztalatok a btbtx-el?"

Bank működik vele.

"mi van ha sérült az index vagy a tábla?"

Röviden: Elő kell venni a mentést.

Hosszabban: Nincs külön indexfájl. Az adatok és az indexek ugyanabban a fájlban vannak. Az indexeket lehet manipulálni a bti.exe utilityvel (indexel, indexet töröl, listáz). Ha egy indexet törölnek, akkor az általa elfoglalt lapok a szabadlistába kerülnek.

Nincs bonyolult védelem (pl. napló) a sérülések ellen. Tehát, ha egy szerencsétlen pillanatban megállítják a programot, akkor az adat és index inkonzisztens állapotba kerülhet. Annyi védelem azért van, hogy a blokkolható szignálok a módosítások ideje alatt blokkolva vannak, tehát CTRL-C nyomkodással nem lehet sérülést okozni. Ha egy fájl annyira megsérül, hogy az adatlapokat nem lehet olvasni, akkor ki kell dobni (nem tudok ilyen esetről).

--
CCC3

Régi Clipperes reflex, hogy mi van az elromlott indexekkel. A CCC alkalmazásokban nem szoktak elromlani az indexek.

1) A régi DOS/Novell/Clipper környezetben az okozta az index hibákat, hogy az alkalmazás az instabil DOS-on futott, bizonytalan hálózaton tartott kapcsolatot az (instabil) filészerverrel, ráadásul az alkalmazást a júzer bármikor leállíthatta. Legkevésbé az DBFNTX szoftver volt a hunyó.

2) A CCC környezetben a stabilitás a következőkön alapszik: A Linux/UNIX/WindowsNT szerverek ritkán szállnak el (légkondicionált szerver szoba). Az I/O nem halózaton át filészerverre történik, hanem lokális. A júzerek nem piszkálhatják az alkalmazást futtató szervert, hanem terminálon át dolgoznak. Ha mégis gáz van, akkor elő kell venni a mentést.

Egyébként, a sima pack úgy működik, hogy a nem törölt rekordokat kíírja egy másik fájlba, azután felépíti az indexeket. Régen a nem törölt rekordok gyűjtése egyáltalán nem nézett semmilyen indexet. A mostani packolás a recno index szerint halad, hogy megőrízze a rekordok sorrendjét. Tehát, ha csak a recno index ép, akkor már működik a pack, újra lehet építeni az egész táblát.

--
CCC3

( ffb | 2007. 02. 08., cs – 22:34 )

azt tapasztaltam (most ismerkedek a btbtx-el), hogy a karakteres mezőket az index nem rakja abc szerint sorba, az ékezetes betűk
a sor végére kerülnek..

pl Őrkény Tasnádi után van.

hogy lehet ezt megkerülni, orvosolni?

Nehezen. Talán kell egy külön mező, ami szerint rendzezni lehet. Az a problémám, hogy egyáltalán nem emlékszem, hogy a btbtx-ben mi van a karakteres (C) és bináris (X) típusokkal, és most nincs is időm utánanézni.

Azért megnéztem:

Az X és C típusú mező között az egyetlen eltérés, hogy a C típusú adat kiolvasásakor van még egy plusz bin2str konverzió. A C típus UTF-8 kódolással tárolódik, de a mezőszélesség byteban van mérve. Pl. egy C10 mezőbe 10 darab 'a' vagy 5 darab 'á' betű fér. A rendezés byteok szerinti lexikografikus, ami nem túl szerencsés, de nehéz volna rajta javítani.

Még szerkesztve:

Elfelejtettem, hogy a bank CCC2-es btbtx-szel működik, abban még nincs külön X és C típus, úgyhogy a CCC3-as btbtx-ben új részek is vannak, ami miatt nem árt az óvatosság.

--
CCC3