[SOLUCIONADO] Error al realizar dbimport

[Javier Zeitune]

Buenos días, les escribo por lo siguiente, tenemos que hacer la migración de G2 a G3 de una Facultad, para trabajar más comodo realice un dbexport de la base y trate de levantar ese export en mi instancia local. Resulta que inicialmente tuve que cambiar el DBDATE a Y4MD para que me tome el archivo, pero ahora tengo el siguiente error

*** put loadcur
1218 - String to date conversion error

Inicialmente la configuración de la variabl de entorno era DMY4/, pero esto me daba el error

Código: [Seleccionar]

invalid month in date
Tienen alguna idea de cómo puedo levantar el error de string conversion?

Muchas gracias

[Alejandro Delú]

Abri alguno de los archivos de datos de alguna tabla que tenga el campo fecha y fijate que formato tiene.
Probaste con MDY4/ ?

https://www.ibm.com/docs/es/informix-servers/12.10?topic=formats-dbdate-variable-deprecated

[Javier Zeitune]

Alejandro, las fechas están expresadas de la siguiente manera: 2020-05-6 hh:mm:seg

Es por eso que había probado Y4MD- , pero al hacer el dbimport <mi base> -l me surge el error.

[Ignacio Bisso]

Hola

Podes identificar mirando hasta donde avanzo el dbimport la tabla que falla ?

En ese caso intenta crear una tabla con el mismo esquema (puede tener otro nombre ), el esquema de la tabla lo podes obtener del archivo sql del dbexport

luego hace un load de esa tabla individual, usando el archivo UNL que genero el dbepxport para esa tabla

te va a decir en que nro de renglon del UNL esta el problema, al menos asi podes diagnosticar el origen del problema y ver si con alguna variante del DBDATE se resueve, (por ahi tenes un caracter no numerico y no se resuelve con DBDATE)

saludos

[Alejandro Delú]

Quizás es AÑO-DIA-MES  entonces el formato es:  Y4DM-

[Javier Zeitune]

Ignacio / Alejandro, gracias a los tips, encontré lo siguiente, la tabla en la que se frena es app_versiones que se carga con el UNL app_v00125, el tema es que tiene 2 campos fechas y están ingresadas de manera diferente, por ejemplo

CRE2.07.0-01|03/29/2012|2012-03-29 17:32:26|1|

La primera en formato  MDY4/ y la segunda fecha está como en todos los otros UNL Y4MD-

No queda otra que cambiar a mano la primer fecha?

Saludos

[Ignacio Bisso]

si correcto, yo lo cambiaria a mano, que raro que el dbexport lo genera mal... quizas esta mal el DBDATE al momento del dbexport
saludosss

[Alejandro Delú]

Endonces el formato es MDY4/   (por el campo date: 03/29/2012).
Creo que el datetime siempre se exporta yyyy-mm-dd hh:mm:ss.
Tenes que ver los campos DATE.

Si es solo ese archivo que esta el campo date en ese formato entonces editalo y cambialo.
Podes dejar vacio el archivo unl de esa tabla de versiones y la cargas después de importar.

[Javier Zeitune]

Alejandro gracias por la ayuda, el formato finalmente era el que indicabas MDY4/, lo que pasa es que la tabla app_versiones no se por qué extraña razón tiene las 2 fechas con formato diferente.
Una vez superado este tema, ahora tengo el siguiente problemas, al realizar el dbimport me quedo sin espacio ISAM error: no free disk space

Estuve viendo un poco los mensajes en el foro, entonces agregue un nuevo chunk a datos (el datos.009 de 2 gb) pero se llenó de una.
Lo agregué con los siguientes comandos

-copy nul datos.00X
-onspaces -c -d datos -p C:\IFMXDATA\ol_escuelacine\datos.00X -o 0 -s 2000000
-ontape -s -L 0

Es muy raro ya que la DB con la que estoy trabajando no es TAAAN grande. Estoy trabajando con una VM con W2003. Tengo 60GB de espacio en el disco.

Les paso una captura de pantalla de onstat -d y de como tengo los archivos. Qué debería hacer?

Muchas gracias!

[Alejandro Delú]

La base de datos esta creada en el dbspace datos ?
Porque este tiene varios chunk vacios, no puede ser que se llene el dbspace!
Los chunks 6 a 14 son del dbspace datos y estan todos vacios. ¿Porque decis que el chunk 9 esta lleno?

¿O será que la base esta en el root dbspace?

Podes hacer una captura de datos del error que te da al importar la base, y una imagen del estado de los chunks luego del error?

[Gustavo J. Palau]

Javier:

Es sumamente extraño lo que te pasa, yo he tenido muchas veces problemas de espacio para importar una base, pero en general eran dbspaces que ya tenían otra cosa. Con una base chica, un dbspace de 2 GB y 1 solo chunk suele ser suficiente.

Yo tenía por costumbre importar bases creando dbspaces nuevos para la importación. Vemos que ustedes tienen un montón de chunks en el Dbspace de Datos y eso debería ser más que suficiente.

Habría que ver en que momento del import da el error y cual es. Y pienso igual que Alejandro: o están creando la base en el root dbspace o bien el dbspace que se llena es otro el temporal o el de los logs, o el root dbspace (pero no exclusivamente por la base).

Otra prueba que pueden hacer es dividir el script SQL del export, e importar inicialmente SOLO la base, y luego crear todo el resto (Procedures, Triggers, statistics, etc.). Yo lo he hecho muchas veces, y me resultó para hacer importaciones que daban errores.

Saludos cordiales

Gustavo

[Javier Zeitune]

Alejandro / Gustavo muchas gracias por las respuestas, como pueden notar no tengo los conocimientos muy frescos en el tema, lo que quería comentarles es que había agregado un archivo (me imagino por lo que dicen en el dbspace datos ) datos.009 creyendo que con eso estaba ampliando el espacio en la DB. Viendo en detalle la captura de pantalla que había mandado, entiendo que los chunks tienen espacio de sobra.

¿De que forma puedo ver en qué dbsapce estoy realizando el dbimport? ¿Cómo puedo hacer para utilizar el dbsapce datos y no el root dbsapce?

Adjunto pantalla de error. Como se libera espacio en el temporary.000?

Gracias!

[Alejandro Delú]

Mira este mensaje por el dbimport
Si la base no terminó de importarse, vas a tener que borrarla para volverla a importar porque se creó en el dbspace y se generó hasta donde dio error.

Seguramente la importaste en el dbspace root porque fijate que el chunk 1 tiene free = 7722 y en la imagen anterior que habias enviado tenia 165687.

[Gustavo J. Palau]

Javier:

Me da toda la impresión que el import se está realizando en el root dbspace, por lo mismo que comenta Ale.

Cuando se hace un import, se debe indicar como parámetro en cual dbspace se coloca la base. Si no se menciona otro dbspace, se asume que es el root. Adicionalmente, a veces los exports mencionan explicitamente el lugar para colocar índices o datos. Esto lo tienes que revisar SIEMPRE en el archivo SQL del export, antes de importar, además de borrar la base de datos generada en forma inconclusa.

La sintaxis del import es:
dbimport <database> [-X] [-c] [-q] [-d <dbspace>]
  [-l [{ buffered }] [-ansi]] [-ci]
  [{ -i <dir> | -t <tapedev> [ -b <blksz> -s <tapesz> ] [-f <script-file>] }]

Como ves, en el parámetro -d  se le debe indicar donde realizar el import.

Por eso es que yo siempre hice los imports en dbspaces nuevos, de 1 solo chunk, pero teniendo en cuenta las cosas ya mencionadas. Y si en el dbspace de datos ya hay otra base con el mismo nombre, no podrás importarla ....

Saludos

Gustavo

[Javier Zeitune]

Gustavo, excelente!! Ya pude, ingresando el modificador y el dbsapce se importo sin problemas. Lo único que si tuve que hacer es dejar un ontape -c durante la importación porque de otra forma se clavaba.

Muchas gracias por la asistencia!