¿Datos anexados o Creación de Tabla?

[m***@gmail.com]

Hola a todos y gracias por adelantado.

El caso que presento es el de una tabla de unos 200.000 registros que debe actualizarse diariamente.
Esa actualización comporta unos 1500 registros nuevos, unos 20.000 actualizados, y unos 1500 eliminados.

Actualmente aplico una consulta de creación de tabla, eliminando la tabla del dia anterior y volviendo a cargar los 200.000 registros ya actualizados, asumiendo que pierdo el diseño de la tabla.

Lo ideal seria una consulta de eliminación de todos los datos seguida de una consulta de datos anexados de los 200.000 registros del dia, conservando de esa manera el diseño de la tabla, formatos de campo, etc.

El problema es que observo que este segundo procedimiento me lleva muchísimo tiempo, llegando incluso a colapsar la aplicación.

De la misma manera, intentar partir esta operaciòn en tres consultas (datos anexados para los nuevos registros, actualización para los existentes y consulta de eliminación para los eliminados) también consume muchísimo tiempo y llega a colapsar la aplicación en la fase de actualización.

Alguien tiene respuesta sobre la diferencia de estos tipos de consulta de acción y qué método puede resultar más eficiente en mi caso?

Quizás algun truco para que la consulta de datos anexados o la de actualización fluya más rápidamente?

Muy agradecido de antemano.

Saludos.

Carlos

[José Mª Fueyo]

Hola
No nos comentas que versión de Access utilizas.
Para la actualización e inserción ¿tienes creado algún índice? tanto para la table de destino como la de origen.
Aunque Access de forma nativa no soporta la instrucción TRUNCATE TABLE, sí lo he visto usandola a través de Application.CurrentProject.Connection.Execute, aunque sospecho que te puede dar problemas de interbloqueo por dejar conexiones abiertas.
Un DoCmd.RunSQL "DELETE FROM Tabla;" ¿te retarda mucho?
Salu2,

José Mª Fueoy

[m***@gmail.com]

Hola, Jose Mª. Gracias por contestar.

La versión de Access es 2010.
La instrucción DELETE FROM... se ejecuta con bastante rapidez. El problema viene a continuación con CREATE TABLE... (200.000 a 250.000 registros) con unos 20 campos, la mayoria índices Entero Largo, tarda unos 45 minutos en ejecutarse, si nadie le sopla...


El planteamiento inicial, y creo que el más lógico, se basaba en actualizar registros (INSERT INTO) y sólo añadir los nuevos del dia anterior, pero ese proceso de actualización se colgaba.

El comentario fácil és el de "Access no está pensado para eso"... pero es mi herramienta... y con ella hemos hecho cosas impensables, muchas gracias a foros como este.

Me dices que es importante que ambas tablas tengan un PK, un índice único y és así.

Saludos

Post by José Mª Fueyo
Hola
No nos comentas que versión de Access utilizas.
Para la actualización e inserción ¿tienes creado algún índice? tanto para la table de destino como la de origen.
Aunque Access de forma nativa no soporta la instrucción TRUNCATE TABLE, sí lo he visto usandola a través de Application.CurrentProject.Connection.Execute, aunque sospecho que te puede dar problemas de interbloqueo por dejar conexiones abiertas.
Un DoCmd.RunSQL "DELETE FROM Tabla;" ¿te retarda mucho?
Salu2,
José Mª Fueoy

[José Mª Fueyo]

Hola de nuevo
¿Tienes algún criterio de selección, o haces alguna combinación entre tablas? de ser así, deberías crearte los índices correspondientes. Puedes crearte hasta 32 por cada tabla, y puedes incluir varios campos por cada tabla.
Salu2,

José Mª Fueyo

[José Mª Fueyo]

Post by José Mª Fueyo
Hola de nuevo
¿Tienes algún criterio de selección, o haces alguna combinación entre tablas? de ser así, deberías crearte los índices correspondientes. Puedes crearte hasta 32 por cada tabla, y puedes incluir varios campos por cada tabla.
Salu2,
José Mª Fueyo

Perdón, quería decir que podías incluir varios campos por cada índice.
Salu2,

José Mª Fueyo

[t***@gmail.com]

Post by José Mª Fueyo

Post by José Mª Fueyo
Hola de nuevo
¿Tienes algún criterio de selección, o haces alguna combinación entre tablas? de ser así, deberías crearte los índices correspondientes. Puedes crearte hasta 32 por cada tabla, y puedes incluir varios campos por cada tabla.
Salu2,
José Mª Fueyo

Perdón, quería decir que podías incluir varios campos por cada índice.
Salu2,
José Mª Fueyo

[m***@gmail.com]

Hola y gracias de nuevo.

En efecto, la consulta de creación de tabla (o de actualización) combina múltiples tablas.

Intento averiguar cuál de los dos planteamientos és más eficiente en el manejo de gran cantidad de registros (250K): el de actualizar y añadir los nuevos registros o el de crear directamente una nueva tabla.

De momento probaré a indexar todos los campos susceptibles de serlo, a ver cuanta mejora puede suponer en uno u otro sistema. Mis tablas tienen los índices básicos (en el autonumérico y en los campos ID de relación con otras tablas).

Las pruebas con tal cantidad de datos requieren mucho tiempo pero compartiré conclusiones a medida que las vaya alcanzando.

Muchas gracias por el interés.

[José Mª Fueyo]

Hola
Prueba los dos modos: recreación de la tabla, y borrado y volcado.
Sí usas algún campo para critérios, indéxalo también.
Y sí decides recrear la tabla, y vas a necesitar índices para extracción de información, esto te puede ser útil: https://support.office.com/es-es/article/instrucci%C3%B3n-create-index-2aa192ea-bde6-4f2a-ab3e-4ed690b75eb2

Salu2,

[j***@gmail.com]

Hola, puedes hacer que tus consultas de acción sean más rápidas y usen menos memoria, si las configuras para que No USEN TRANSACCIONES, esto se configura en las propiedades de la consulta en modo diseño, usando botón derecho del mouse sobre el área de las tablas de la consulta, y seleccionando PROPIEDADES. Ahí buscas la propiedad USAR TRANSACCIONES y lo cambias a NO. Con esto logras que Access ejecute las acciones sin guardar en la memoria los datos afectados en la consulta de acción por si te arrepientes de hacerlo. Por ejemplo, una consulta de eliminación de 100 mil registros, en condiciones normales, se reserva la memoria para cuando aparezca la confirmación de la acción... "Esta seguro de eliminar x registros?"... Si te arrepientes, la acción no se concreta y se devuelven los registros a su estado normal antes de la eliminación. Con la opción que te comento, no hay pregunta final, y la eliminación se realiza rápida, pero sin posibilidad de arrepentirse, así que ojo ahí. Una consulta sin transacciones, se demora 5 veces menos que una consulta que las utilice.
Saludos
Jd

[m***@gmail.com]

Muchísimas gracias. Cuando tenga conclusiones las compartiré.

[t***@gmail.com]

Post by m***@gmail.com
Muchísimas gracias. Cuando tenga conclusiones las compartiré.

[t***@gmail.com]

Post by m***@gmail.com
Muchísimas gracias. Cuando tenga conclusiones las compartiré.

[t***@gmail.com]

Post by m***@gmail.com
Hola a todos y gracias por adelantado.
El caso que presento es el de una tabla de unos 200.000 registros que debe actualizarse diariamente.
Esa actualización comporta unos 1500 registros nuevos, unos 20.000 actualizados, y unos 1500 eliminados.
Actualmente aplico una consulta de creación de tabla, eliminando la tabla del dia anterior y volviendo a cargar los 200.000 registros ya actualizados, asumiendo que pierdo el diseño de la tabla.
Lo ideal seria una consulta de eliminación de todos los datos seguida de una consulta de datos anexados de los 200.000 registros del dia, conservando de esa manera el diseño de la tabla, formatos de campo, etc.
El problema es que observo que este segundo procedimiento me lleva muchísimo tiempo, llegando incluso a colapsar la aplicación.
De la misma manera, intentar partir esta operaciòn en tres consultas (datos anexados para los nuevos registros, actualización para los existentes y consulta de eliminación para los eliminados) también consume muchísimo tiempo y llega a colapsar la aplicación en la fase de actualización.
Alguien tiene respuesta sobre la diferencia de estos tipos de consulta de acción y qué método puede resultar más eficiente en mi caso?
Quizás algun truco para que la consulta de datos anexados o la de actualización fluya más rápidamente?
Muy agradecido de antemano.
Saludos.
Carlos