FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Error en alta masiva de datos en una sóla transacción
Hola.
He terminado una contabilidad y estoy haciendo los correspondientes traspaso de datos de la antigua aplicación a la nueva, con FB 2.0, IBX y D7. El asunto es que llego a importar de 60.000 a 196.000 registros y aleatoriamente, y nunca en el mismo sítio, incluso repitiendo en las mismas condiciones, me sale el siguiente error "statement already has a cursor 0000000 assigned" (donde los ceros es un númeraco gordo) y gracias a un try except el único problema es que pierdo un registro. Este error sólo se produce una sóla vez en toda la importación y llevo hecho ya más de 30 importaciónes. Si meto el commitretaining tras cada posteo no hay problema, pero se multiplica el tiempo de importación por diez (bueno, no tanto). ¿Alguien tiene idea? Gracias. |
#2
|
|||
|
|||
Continúa el problema
Sigo con el mismo problema, pero pasa algo curioso. Cuando pongo a cargar registros en la base de datos desde un fichero plano empieza muy rápido (tengo puesto un contador visible en pantalla que se actualiza cada 10 altas), pero poco a poco se va ralentizando... los 10.000 primeros lo hace en menos de cinco minutos y los 20.000 siguientes en más de 50 minutos, llegando a tardar una hora el alta de 30.000 registros. Si divido el fichero plano en ficheros de 5.000 registros y los cargo consecutivamente, tardo menos de 15 minutos y evito el error del 'cursor declarado'. Así que decidí, cada 1000 registros, cerrar la transacción y volverla a abrir, incluso cerrando y abriendo las dos tablas que entran en el juego. Mi sorpresa es que se seguía ralentizando de la misma manera, y el fallo del cursor permanecía. Tenía que cerrar el form y volverlo a abrir, para que se crearan de nuevo los objetos (Transacciones y queries). ¿Alguien ha notado esto?
|
#3
|
||||
|
||||
No soy gurú en estos temas, pero diría que el commitRetaining no es apropiado, deberías hacer un commit cada 1.000 registros (por decir un número, puede que no sea el adecuado, quizás con 500 vaya más rápido).
Al realizar un commit, tienes que cerrar y abrir de nuevo los datasets para ver los cambios; puesto que se trata de una importación, no debería importar ese detalle, ya que los datos no los mostrarás en pantalla. En resumen: realizas 1.000 importaciones, haces el commit y después continúas con la importación. Eso si, al terminar la importación, tienes que cerrar las tablas y volverlas a abrir para ver los datos. Por otra parte, no usaría IBX puesto que el proyecto Firebird se separó de los IBX hace tiempo, podría haber incompatibilidades entre IBX y Firebird (aunque no creo que el problema actual sea ese). Siempre puedes utilizar MDOLIB que sigue al proyecto Firebird. Saludos y suerte.
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
#4
|
|||
|
|||
Gracias.
Gracias por tu respuesta y perdona la tardanza, me he tomado un par de días por asuntos personales. He probado lo del commit, sigue igual. Sin embargo, no sabía nada del tema de las IBX y las MDOLIB que comentas, voy a probar inmediatamente.
Gracias de nuevo. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
controlar error en transacción | kikodelphi | MS SQL Server | 2 | 12-05-2006 03:53:09 |
DbExpress:Varias consultas,una sola transaccion | josemmerida | Conexión con bases de datos | 0 | 13-05-2005 19:11:56 |
DbExpres: Dod Bases de Datos, una sola Transacción. | josemmerida | Conexión con bases de datos | 1 | 09-02-2005 20:43:58 |
Backup de varias DB en una sola transacción. | josemmerida | Firebird e Interbase | 2 | 05-11-2004 14:07:50 |
Error al dar de alta un registro | perla22 | Tablas planas | 1 | 17-05-2004 17:49:38 |
|