![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
|||
|
|||
|
Yo estoy mas cerca así que mi respuesta debería llegar mas rápido...
![]() Bueno fuera de bromas, amigo como dicen los colegas comparte un poco de código para ver que podría estar provocando la lentitud... Un abrazo. |
|
#2
|
||||
|
||||
|
Gracias a todos por participar.
Nobleza obliga, les dejo como lo hice. Tuve que optimizar los StoreProc de la base de datos y el codigo, pero funciona bien. En 1 Hs está procesado. En la Db de Firebird cree 2 tablas temporales (una para cada alicuota) sin indexar, con campo CUIT y ALICUOTA. Mi tabla del padron principal tiene 3 campos: CUIT / Ali_Percep / Ali_Reten indexado con clave sobre el primero. El proceso se hace desde el sistema disparando diferentes SP en la DB. Primero un SP hace el borrado de las tablas temporales. Luego cargo en un TStringList uno de los archivos para obtener los datos necesarios y almacenarlos en la tabla temporal correspondiente con un proceso similar a este: <DELPHI>
Si todo anduvo bien (yo utilizo banderas de status, pero lo anterior puede encapsularse en una funcion que devuelva True/False y obrar en consecuencia) entonces unimos mediante otro SP encargado de unir en el padron definitivo las alicuotas existentes en las dos tablas temporales:
------ <FIREBIRD> En la DB, el SP encargado de unir a la tabla del Padron definitivo las alicuotas existentes en las dos tablas temporales es esto:
Saludos a la comunidad,
__________________
Gracias de antemano por vuestra ayuda. ·.:*:.·Yako·.:*:.· |
|
#3
|
||||
|
||||
|
Ufff... yo haría todo bastante diferente
![]() Para empezar quitaba ese Application.ProcessMessages porque lo enlentece muchísimo (pondría simplemente el cursor del ratón con el reloj de arena). Tampoco haría un commit cada 500 registros, si son varios millones, los haría al menos cada diez mil o algo así, tendría que hacer pruebas. Además aprovecharía en ese instante que hace commit para hacer el application.processmessages Luego, lo de pasar a un stringlist y luego a una tabla en memoria... no acabo de entenderlo, en principio me parece trabajo doble. En fin, que tendría que conocer mejor todo lo que haces para decidir una cosa u otra.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#4
|
|||
|
|||
|
Estimado hgiacobone si me lo permite, quisiera proponer algunos cambios, pienso que podría mejorar el rendimiento.
1) Leer el archivo de texto sin pasar por la carga de este a un TStringList. 2) Evitar el uso de tablas temporales y realizar la inserción o actualización en la tabla final (PADRON) 3) Modificar procedimiento almacenado que realiza el merge de las tablas temporales. Por supuesto puede ser que mi mirada no cumpla con sus requerimientos, A ver que le parecen.
Espero que mi pequeño aporte le ayude a mejorar el rendimiento de su proceso. NOTA: Tome en cuenta que el conteo de las lineas del archivo para mostrar la barra de progreso puede ser omitida para mejorar mas el rendimiento Saludos cordiales |
|
#5
|
||||
|
||||
|
Gracias
Cita:
__________________
Gracias de antemano por vuestra ayuda. ·.:*:.·Yako·.:*:.· |
![]() |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Delphi RoadMap 2014 - disponible! | el-mono | Noticias | 13 | 06-04-2014 22:37:22 |
| El USB del futuro llega en 2014 | nlsgarcia | La Taberna | 2 | 12-12-2013 11:37:31 |
| Padrón telefónico | rruffino | SQL | 2 | 09-08-2008 16:27:02 |
| Padron fotografico | alcides | Varios | 1 | 13-10-2007 18:39:26 |
| Más problema padrón observador | adpa | OOP | 5 | 07-02-2007 20:19:15 |
|