[Megoldva] Üres cella értéke másik munkafüzetből

[kea]

Kedves Tanult Fórumtársak!

LibreOffice 6.1.4.2 Calc. Adottak számosan munkafüzetek, amelyekben jelszóvédett munkalapok vannak. Ezek adott celláiból szedem ki az ott lévő értékeket (szöveges konstans). Ha a hivatkozott cella nincs kitöltve, a várt 0 jön át -- többnyire. Néha -- és tényleg csak néha -- azonban semmi, ami az összesítésből generált csv szerkezetét szétrúgja. Mi lehet az ok, miért van az, hogy eseti kivételként egy egyébként üres cella értéke nem 0-ként jön át, hanem semm nem jön át?

Köszi, üdv:
KEA.

[Zizi64]

Az

• alkalmazott Cellafüggvények,

• a forrásfájl munkalapjai védelmének,

• a forrásfájl rendelkezésre állásása (ugyanazon a gépen van, vagy valahol a hálózaton, és meg van nyitva? Van jogosultságod az eléréséhez?)

az ismerete nélkül hogyan lehetne bármit mondani a dologról?
Kérlek töltsél fel ide KIS MÉRETŰ példafájlokat. 128 KiB a méretmaximum itt, ezen a fórumon. Egy forrásfájlt, és egy célfájlt legalább. A szöveges adatokat kicserélheted benne nem érzékeny szövegekre, de a szerkezet, a védelmek, a képletek ugyanazok legyenek, mint az éles fájlokban.

üres cella értéke nem 0-ként jön át, hanem semmi nem jön át

Az attól is függ, hogy számértéket, vagy szöveget hivatkozol a másik fájlból. Egy üres cella szövegértéke a "semmi" (üres string, nullstring) számértéke meg 0.

LibreOffice 6.1.4.2 Calc.

Én se itthon, mi se a cégnél nem frissítünk mindig a legújabb LO verzióra, mert ki tudja milyen új apróság nem stimmel benne. Az ismert hiba jobb, mint az ismeretlen. De azért a te verziódat már én is réginek gondolom, ideje lenne frissíteni. Egy reménybeli segítőnek ilyen kor elő kell vakarnia valahonnan legalább egy hordozható verziót, és azon próbálni a dolgot - már ha a konkrét verzióból létezett egyáltalán hordozható is.

____________________________________________
OpenOffice 3.1.1 Slackware Linux 13-on

A főrumbeli aláírásod még elavultabb. Azt lehet szerkeszteni a profilodban és be lehet írni a valóságot. (A regisztrációkor már akkor se lehetett a legújabb verziókat kiválasztani, amikor én regisztráltam... Te és most leírtad a szövegben, hogy mit használsz, de jobb az ha az aláírásban is ott a nagyon fontos információ.)

[kea]

A jelenség eseti kivételként fordul elő, a legközelebbit kisorolom mintának. Minden a helyi gépen van, a képlet semmilyen műveletet nem végez a hivatkozott cellával, csak az értékét veszi át (kb. 140 munkafüzetből fix cellakoordináták alapján). A hivatkozott cellákban szöveg van (sql parancsok) vagy üresen marad (legrosszabb esetben bármit is írnak bele, de az nem jellemző). Aláírás javítva, köszi!

[kea]

Na van megint egy példa. Csak hogy érdekesebb legyen a történet: 124 munkafüzet (egylaposak) adott, teljesen egyforma szerkezettel. Ezekből szedem ki hallgatónként az adott cellákban lévő értékeket (mint az adott kérdésre adott hallgatói választ), tehát nem végzek vele semmilyen műveletet ekkor még. A képletek így néznek ki:

='file:///home/kea/06/FDE_06c.ods'#$Munkalap1.B36
='file:///home/kea/06/FDE_06c.ods'#$Munkalap1.B51

Az üres B36-ból átjön a nulla, az ugyancsak üres B51 meg kimarad, mintha ott sem lenne, Ez utóbbi miatt pedig borul a további feldolgozás, amíg kézzel nem javítom az összesítésből mentett CSV-ben. Az input ods-t viszont nem szeretném tök nyilvános helyre föltölteni, mert a hallgató neve meg gédépéerr. El tudom küldeni magánban?

[Zizi64]

Ez nem használható példafájl, ez csak két link. Ne várd el, hogy mi hozzunk létre a linkjeid alapján példafájlokat! Már csak azért se, mert ha valami hiba van a te fájljaidban, azt nem biztos, hogy mi is elkövetjük.
Olyan forrásdokumentumot preparálj, ami nem tartalmaz konkrét érzékeny adatokat. Nem biztos, hogy pont én fogok/tudok segíteni neked.

[kea]

Nem várom el Azért másoltam be, hogy megmutassam, a legegyszerűbb, bármiféle művelet nélküli értékátvételről van szó. Ha beleírok a problémás file-ba, majd mentem, akkor az már nem az eredeti Viszont úgy néz ki, hogy ennek ellenére megmarad az anomálisa, Tehát adott a nem eredet, de a jelenséget (nálam) továbbra is bemutató FDE_06c.ods file, csatolva. Valamit adottak a hivatkozó képletek leegyszerűsítve a két különbözőképpen viselkedő cellára (keplet.csv, csatoltan). A keplet.csv-ben értelemszerűen módosítandó az elérési útvonal annak megfelelően, hova teszed az ods-t. Ha ezután a keplet.csv-t a Calc-ban megnyitod, a hivatkozott első, üres cellát kiszedi 0 értékkel, a másodikat meg üresen hagyja. És ez érdekelne roppantul, hogy mitől van. Mondom, igen ritkán, ezrelékekben mérhető darabszámban fordul elő, de így mindig ellenőrizni kell és kézzel javítani, mert különben hibára fut a további feldolgozás.

[Zizi64]

A két üresnek látszó cella tartalma erősen különböző!

Lásd a visszaküldött, plusz egy munkalappal kiegészített fájlt! Mivel jelszavas az eredeti, azon tudtam megmutatni, hogy miről van szó.

FDE_06c_Zizi64.ods

(19.34 KiB) Letöltve 5 alkalommal.

A gondot az okozza, hogy az 51-es sorban van egy Ctrl-Enter (soremelés) karakter a cellában, ami SZÖVEGES-sé teszi a tartalmat a valóban üreshez képest, ami még lehet bármilyen típusú, ha valamit beleírsz.
Az eltérő típusú tartalmak természetesen máshogy is működnek. Láthatod: még azonos fájlon belül is!
Meg kell vizsgálnod a cella tartalmát, a tartalom típusát, és aszerint "importálni" a másik fájlba.

[Zizi64]

A keplet.csv-ben értelemszerűen módosítandó az elérési útvonal annak megfelelően, hova teszed az ods-t.

Ezt meg tudja oldani a LibreOffice.
Csak be kell kapcsolni a relatív hivatkozások mentése opciót, és ugyanabba könyvtárba tenni a forrás és a célfájlt. Ezek után ha máshová, de továbbra is azonos könyvtárba mented a fájlokat, akkor "frissülni" fognak a hivatkozások is.
Ez nem lehetetlen külön könyvtárban lévő fájlokkal se, de a két fájl közötti könyvtárszint-viszonynak és könyvtárneveknek a kettő között azonosnak kell maradni. Csak a felsőbb szintek változhatnak ez esetben.

RelatívURL.png (31.49 KiB) Megtekintve 150 alkalommal

[kea]

Nagyon köszi! Azért gáz, mert nekem is eszembe kellett volna jusson, hogy hátha van a cellában valami láthatatlan, de túlkomplikáltam. Az járt az eszemben, hogy esetleg ha törölte a cella tartalmát (del / Ctrl-X), akkor mi van, de nem ez volt az.

Ami viszont érdekes továbbra is, az a Ctrl-Enterek kezelése. Ugyanis a további feldolgozás során csinálok egy másik munkalapra irányított beillesztést (csak értékek), majd ott cserélek minden \n-t szóközre (mint regexp), és utána mentés csv-be. Ahol a cellán belül több sor van, azok ettől rendben lesznek, de akkor ez a csere miért nem találja meg az egy darab szingli Ctrl-Enter-t?

[Zizi64]

Ami viszont érdekes továbbra is, az a Ctrl-Enterek kezelése. Ugyanis a további feldolgozás során csinálok egy másik munkalapra irányított beillesztést (csak értékek), majd ott cserélek minden \n-t szóközre (mint regexp), és utána mentés csv-be. Ahol a cellán belül több sor van, azok ettől rendben lesznek, de akkor ez a csere miért nem találja meg az egy darab szingli Ctrl-Enter-t?

Erre megint kell példafájl. Az eredeti soremelés karakterrel is legyen benne cella, meg az általad kicserélt karakterekkel is.
Meg a csere menetét is írd le pontosan.

Nagyon köszi! Azért gáz, mert nekem is eszembe kellett volna jusson, hogy hátha van a cellában valami láthatatlan, de túlkomplikáltam.

Nem biztos, hogy a kitöltő nyomott Ctrl-Enter-t. Elég ha valahonnan beillesztett egy olyan tartalmat, amiben volt valamilyen soremelés karakter, és nem törölt aztán mindent.

[kea]

Érdekes. A kód() fv. szerint egy ascii 10-es van a cellában. Ha kopipaszta útján belecsempészek egy Enter-t (remélhetőleg azt), arra is ezt adja. A csere ezt is kicseréli egy darab szóközre. Megnézem holnap, hogy ez az egy darab szóköz a feldolgozás melyik lépésében tűnik el. Mindenesetre rdekes.

[kea]

A probléma nincs megoldva, csak átterelve más területre. Kicseréli a problémás helyen is egy darab szóközre. A mentett csv-ben (igazándiból tsv;) ez még benne van: <tab><szóköz><tab> formában, ahogy kell. Viszont amikor ezt szétdarabolja egy bash script, amiben a lényegi elem (esetünkben) az, hogy... | cut -f 2,11, és ez lenyeli, elsikkasztja a szóközt. Marad a neptun-kód, a tabulátor és rögtön utána az enter. Szóval nem a libre okozza a problémát. Köszönöm a segítséget!

[Zizi64]

Köszönöm a segítséget!

Szívesen, máskor is!

...esetleg próbáld meg másféle karakterre cseréni a "kocsivissza" karaktert. Hátha pont a szóközre háklis a rendszered: lehet mondjuk kötőjel, vagy bármi egyéb...

[kea]

Pontosítom: nem a cut nyeli le a szóközt, hanem a következő lépésben tűnik el
while read sor ; do ... echo -n $sor ... done < inputfile > outputfile
Nyilván meg tudom barkácsolni, és cserélni fogom előzőleg a tab szóköz tab hármast egy tab nulla tab-ra, mert az adott helyzetben amúgy is nullának kellene ott lennie (ami, ugye, a tényleg üres cellákból jön át).