Dotaz: OpenOffice tabulka a více jak 32000 řádků

[Stan.M.]

Zdravím,

nevíte někdo jestli lze a případně jak zvýšit počet řádků v tabulce Open Office. Bohužel mi těch 32000 nedostačuje :( Používám českou verzi 1.1.0 předkompilovanou jak pro linux tak pro windows.

dík

Odpovědi

[espinosa@centrum.cz]

No, ja jsem si jednou sam externe vygeneroval tabulku, ktera mela vyssi pocet radku (ted uz nevim, tak okolo 50000?? uz je to dyl) OO pouziva zazipovany XML, takze to neni problem vygenerovat i pro PHP :)) ....ALE kouslo se to. Zacalo nacitat a konec, bylo nutne killnout :( OpenOffice 1.0.1 original od RedHatu 9 Ja bych rekl, ze obecne (nejen pro tabulky a Calc) s velkymi XML ma problem XML parser a na nem to zatuhne. Ted mam 1.0.1 primo z OO.org ale nezkousel jsem. Nevihoda XML formatu, zvlaste pokud chceme pouzivat pristup ala DOM, je fakt, ze se musi nacist do pameti cely a naparsovat cely! Microsofti DOC/XLS byl konstruovan tak, aby nemusel (v te dobe by se ani do pameti PC velky dokument nevesel) tyhle formaty maji na zacatku neco jako FAT na disku, takze si muzou casti vybirat. Coz ma zase jine nevyhody, ktere bych tu nerad diskutoval, to je namet na samostatne forum! Nevim nic o "postupnych" parserech XML - nacetl by a naparsoval jen vybranou cast rozsahleho dokumentu - ale teoreticky by neco takoveho mohlo existovat. Mymochodem, nezkousel nekdo OO 1.1 z RedHatu Rawhide nebo Fedory? Funguje to i pod RH9 ? Ja vim, mixovat s RawHide se nema a o Fedora redhatu, alias novem beta RH10, nevim nic. Ale kompilovat src.rpm se mi nechce, nemam potrebne volne gigabajty :)

[Aloner]

On ma OOfice (Calc-Linux) obecne problem s velkymi soubory dat. Zkousel jsem do Calcu nahrat velky CSV soubor (v radech 10tis. radku) a masina se mohla uswapovat k smrti (upozornuju, ze mam 256MB RAM + 512MB swap), po 30minutach zbesileho swapovani jsem to musel killnout, jinak by to swapovalo dodnes

[Ladislav Jancik]

Pokud chcete zpracovat vice jak 32000 radku v OOorg nebo v Excelu, tak radeji pouzijte nejakou databazi. Za prve budete mit rychlejsi vystupy a za druhe budete mit reseni i do budoucna, kdy pocet zpracovavanych radku poroste. Resil jsem podobnou vec - zakaznik nejprve pozadovat 5000 radku, potom 8000, potom 10000 a v tu chvili jsem se zastavil a predelal to na db reseni. A je po ptakach. Zakaznik je spokojenej a jede mu to jako z praku i pri 50000 radkach. Lada Jancik

[unchallenger]

Moje řeč. V 32k řádků si stejně nikdo nebude malovat nic myší po jednotlivých položkách, to se zpracovává jedině hromadně, a k tomu je DB mnohem vhodnější nástroj. Nemusíš zrovna rozjíždět nějaké monstrum, např. SQLite by mohlo být použitelným řešením a budeš-li se držet standardního DB API v Pythonu či Perlu, můžeš později přejít na MySQL, PostgreSQL a další DB změnou pár řádků...

[Tomáš Bláha]

32000 je maximum, někde jsem na stránkách četl plán na zvýšení limitu, který zjistil, že je potřeba upravit hodně částí kódu a časovou náročnost stanovil na měsíce. Nejsem si jistý, zda na tom někdo vůbec začal pracovat.