Mailinglist Archive: opensuse-es (2314 mails)

["Carlos E. R." <robin.listas@xxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


El 2007-01-18 a las 22:55 +0100, Camaleón escribió:

> > Ha importado 13903 lineas - pero no se cuantas hay en realidad.
> 
> 15.148. Si lo abres con Kwrite se ve correctamente.

En otra parte del correo digo que abro las 15155 lineas como texto en OOo. 
El fichero aumenta por minutos, cuando te lo vuelves a bajar ha aumentado.

> 
> > ¿Y los otros formatos que hay, como xml, sirven?
> 
> No, porque necesito eliminar algunas columnas, por eso la necesidad de
> pasarlo a una hoja de cálculo.

Iba a probarlo otra vez, pero no consigo bajarme el fichero xml para 
verlo. El html es otra posibilidad, si es una tabla se puede importar. Se 
queda el firefox esperando pero no lo baja, ni se me abre la ventanita.

> 
> > Tú que conoces la estructura de ese fichero podrías averiguar qué lineas
> > le faltan, en qué falla. ¿Funcionaría un diff si grabamos un csv desde el
> > OO? Quizás no. ¿Grabando sólo el campo indice y comparando cuales indices
> > faltan?
> 
> Ábrelo con Krwite, está todo correcto y verás las 15.000 líneas. Pero
> por algún motivo, al abrirlo, importarlo o pegarlo a Calc se pierden
> datos...

Eso ya lo he dicho. Necesitas un café ;-)

Y que no es por límite de tamaño, sino porque se salta lineas. La prueba 
es que partiendo el fichero original en dos mitades se sigue saltando las 
mismas lineas: la cuestión es averiguar exactamente qué lineas son las que 
se salta, y entonces pensar el porqué.

> 
> > Por cierto, que me tarda un montón en grabarlo como .odt el OOo.
> 
> Mejor sería como .ods ¿no?

.ods, sí, así está. Tarda mucho en grabarlo.



Ya sé porqué falla.

Tenemos las columnas de la A (Level) a la I (Self-explanatory texts in 
German). Pero si te vas a la fila 478 observarás que llega hasta la 
columna IS !!

   0302 21 10;--- Lesser or Greenland halibut (Reinhardtius hippoglossoides);


fila   codigo
477    '030221000010
478    '030221000080"  ---- fila muy larga
479    '030341900080

El problema ocurre en la celda I478, que la interpreta como:

Heilbutt Reinhardtius hippoglossoides, Hippoglossus hippoglossus, Hippoglossus stenolepis", frisch oder gekühlt" "6"

Cuando en realidad el "6" pertenece a la fila siguiente. No veo ningún 
problema en el fichero .csv del cual toma esos datos, las lineas están 
partidas correctamente (después de convertir los retornos de carro, ojo).

El problema está en las comillas que "ve" el OOo.Veamos:

CSV:

;"Heilbutt "Reinhardtius hippoglossoides, Hippoglossus hippoglossus, Hippoglossus stenolepis", frisch oder gekühlt"

OOo-calc, I478:

 Heilbutt Reinhardtius hippoglossoides, Hippoglossus hippoglossus, Hippoglossus stenolepis", frisch oder gekühlt" "6"
.........^

Falta una comilla ahí, se la ha comido. Al comersela, se desfasa, y el 
campo no se cierra en el "gekühlt" sino después: tan después que sigue 
llenando hasta la columna "IV" y no sigue porque se ha terminado la hoja.


Este problema se repite en varias filas, son fáciles de encontrar (te 
posicioneas en la columna "J" y das ctrl-down para encontrar la siguiente 
celda llena.

Ignoro como solucionarlo. Es un bug del OOo (a no ser que el formato CSV 
no deba llevar comillas internas). Se podría solventar creando un programa 
que lea el CSV y cambie las comillas de string respetando las interiores.


Por cierto, sólo por tener el OOo abierto con el fichero .ods de este 
chisme, me ocupa un 55% de CPU con el OO sin hacer nada. [...] hasta 
pasado un buen rato que se tranquiliza.


- -- 
Saludos
       Carlos E. R.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFFsAK+tTMYHG2NR9URAmjYAJ9Vjwo2blDHAmkUgsA+j6ZtHuxrEgCcDTI/
3Yl3ADKoe+EzFhQxh6oU+JI=
=JI4K
-----END PGP SIGNATURE-----