Sziasztok!
Van egy lecserélés alatt álló clipperes rendszerünk.
Jó lenne a régi rendszerből látni az adatokat és saját lekérdezéseket is gyártani.
A Clippert nem erőltetném amiatt sem, hogy ne kelljen vele varázsolni 64 bites Windowson évek múlva is.
Pláne éppen most nem szeretném ezt megtanulni.
A LibreOfficeban esetleg AutoIT nyelven ez menne is DE:
Vannak helyek ahol a karakter ASCII értéke tartalmazza az információt.
A modern rendszerek elvégeznek egy CP852 -> UTF8 átalakítást és értelem szerűen nem azokat az értékeket kapom vissza amit kellene.
Mielőtt binárisan mennék neki van valakinek megoldása esetleg erre a problémára vagy találkozott már ezzel.
A legkézenfekvőbb irány a LibreOffice Base lenne mert akkor SQL utasításokkal tudom meglépni a feladatot.
Teszem mindezt a kihívásért - talán ezt is meg tudom lépni. :)
- 395 megtekintés
Hozzászólások
Sajnos sehogy máshogy nem fog menni, csak binárisan. Vagy bezárjátok virtualizált-emulált környezetbe. A CP852 kb. semmivel nem kompatibilis, se az előtte lévő kódolásokkal, se az utánuk használt iso-latin1/2-vel, UTF-ekkel.
Clipper helyett nem az AutoIT-et ajánlom, mert az is csak Windows only, hanem a Harbour való állítólag erre, egy xBase/Clipper-kompatilbis, modern, FOSS GPL fordító, multiplatformos, konzolos alkalmazásként szerintem bármire tudsz vele fordítani, minimális átírás árán.
Vagy a másik még jobb, amit írsz, hogy SQL import, és ahhoz esetleges valami webformos frontend.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
hanem a Harbour való állítólag erre
Nem csak állítólag — 10+ éve használjuk, pár soros változtatással le lehetett fordítani a régi Clipper-es ügyviteli rendszert Linuxra, atomstablian működik. Egy időben még DOS-os és 64 bites Linuxos binárist is fordítottunk ugyanabból a forrásból :-)
- A hozzászóláshoz be kell jelentkezni
Úgy kell elképzelni, hogy van egy char meződ, ami mondjuk 'A'-t tartalmaz, de te azt 65-ként értelmezed? Akkor esetleg működhet az, hogy az import során byte típusúvá alakítod.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni
Hát én azt gondolnám, hogy a legkézenfekvőbb irány az RDBMS lenne. Kiolvasod CP852-ben, és betöltöd igény szerint. Ha karakteres a mező, akkor nyilván UTF8-ba kell konvertálni. Ha a bináris érték a fontos, akkor meg olyan mezőbe kell rakni, amiben bináris értékeket lehet tárolni.
- A hozzászóláshoz be kell jelentkezni
Úgy vélek emlékezni, hogy a Clipper egy adatbáziskezelő program(nyelv), ami dBase-szerű adatfájlt használ. ( https://www.clicketyclick.dk/databases/xbase/format/dbf.html ).
Az adattfájl bináris, tehát 'egyben' nem lehet konvertálni, csak a belőle kinyert szővegeket pl. Az iconv-val
- A hozzászóláshoz be kell jelentkezni
Kár, hogy linkelsz valamit, de már a második sort sem olvasod el.
The Data File is a mix of binary and ASCII data. Header contains binary data. The records are all in ASCII (except ofcause the binary objects like pictures).
A header eltávolítása után csak text adat marad a marad az egyetlen törölt rekord jelző kivételével. Tehát az adatban - a fent említett kivétellel - bináris érték nincs. Annyira text, hogy még ^Z-t is biggyesztenek a végére, ami a DOS 2.0 EOF.
"Kézzel" úgy lehet konvertálni, hogy megfejted a header size és type érékeit, majd a header levágása után a rekordok közé rekordszeparátort (pl. LF), a mezők közé mezőszeparátort (pl. PIPE) kell illeszteni. Utána jöhet az iconv.
Azaz mégsem, mert a cp852 csak codepage, ezért érdemes a használt nyelv függvényében egy statisztikát készíteni. Ti. szabályosan használták-e és van-e benne elgépelés. A "csak codepage" azt is jelenti, hogy rendezés esetén, - mint akár az utf* - nem írja le a sort weight és search weight táblákat.
- A hozzászóláshoz be kell jelentkezni
Azért a 18-as pontnál ezt a részt is nézd meg:
Value Description
01h System column (not visible to user)
02h Column can store null values
04h Binary column (for CHAR and MEMO only)
PS: Mindenkitől elnézést kérek, nem tudom, hogyan írhattam azt, hogy 'szővegeket'. Talán ráfogom a telefonra.
- A hozzászóláshoz be kell jelentkezni
(Agresszív kismalac mód on: Nem nézem, öreg vagyok hozzá!)
Úgy 30 éve, mikor a női őltözőben egy asztalon tárolták a "szervert" az egyik ügyfélnél...
Amíg a két kolléga megvacsorázott a kocsmában, addig kijavítottam a diszket, kiskanállal összelapátoltam az adatbázist, eldobtam az indexet és újraindexeltem. Amikor végeztem, már megérkezett a vacsorám és cseréltünk.
Akkoriban nem kellett olvasgatnom, mert fejben volt. Most meg már nem olvasnék más helyett. (A többiek meg fórumoznak. :-D)
- A hozzászóláshoz be kell jelentkezni
Sziasztok!
Köszönöm a tippeket!
Mivel sokad rangú a kérdés és volt most fontosabb nem foglalkoztam vele azóta.
Azokat a mezőket ahol így vannak tárolva az adatok eleve a szükséges függvényekkel töltötték fel.
Elgépelés nem lehet benne.
A szívatás benne az, hogy az ASCII értéke számít ezeknek a mezőknek.
A Harbour projektet már más is ajánlotta (személyesen), de ennyi energiát nem fektetnék bele.
Nem tudom mennyi idő beüzemelni a Harbour-t, és leginkább mennyi idő alatt sajátítanám el.
Ha sztenderd SQL lenne már régen túl lennék a feladaton mert csak statisztikákra lenne szükségem.
Pár napnál több időt pedig nem szánok rá annyit nem ér az egész, főleg most mert sajnos mással is kell foglalkoznom.
A dbf fájlok közvetlen feldolgozását már néztem, de a jelenlegi időkeretemen ez messze túl mutat.
Ennek is csak később futok neki vagy alternatíva ként a Harbour projekttel.
- A hozzászóláshoz be kell jelentkezni
> A szívatás benne az, hogy az ASCII értéke számít ezeknek a mezőknek.
Szerintem azt akarod érzékeltetni, hogy a mező bináris (pl. számot tartalmaz). Ilyenkor kellene az automatikus konvertálóprogramnak nemkonvertálnia, mondjuk a mezőtípus alapján:
https://www.clicketyclick.dk/databases/xbase/format/data_types.html
- A hozzászóláshoz be kell jelentkezni