Crece la base de datos
Tengo una base de datos en access 2000, no puedo migrar de access por compatibilidad con la version de ASP desde la que lausan.
Tengo 40 0 50 tablas de otro tipo de base de datos vinculadas con odbc. Tengo que hacer todo un conjunto de select para crear una única tabla que es la que se usa desde asp
En los procesos de consulta de las tablas vinculadas la base de datos crece hasta que peta el update. Osea ya no permite grabar más cosas en la tabla destino.
En esta situación le paso la compresión y se queda en casi nada (100 megas)
E intentado usar una macro dividir los sql en varias funciones y entre medio hacer un compres de la base de datos, pero no me deja.
Supongo que lo que llena la base de datos son las consultas temporales los recordset, que genero para obtener los datos. Pero no existe ninguna forma de limpiar...
Se te ocurre algo...
Es algo urgente. Aunque supongo que todo el mundo dice lo mismo.
Pero se me han acabado las ideas...
Tengo 40 0 50 tablas de otro tipo de base de datos vinculadas con odbc. Tengo que hacer todo un conjunto de select para crear una única tabla que es la que se usa desde asp
En los procesos de consulta de las tablas vinculadas la base de datos crece hasta que peta el update. Osea ya no permite grabar más cosas en la tabla destino.
En esta situación le paso la compresión y se queda en casi nada (100 megas)
E intentado usar una macro dividir los sql en varias funciones y entre medio hacer un compres de la base de datos, pero no me deja.
Supongo que lo que llena la base de datos son las consultas temporales los recordset, que genero para obtener los datos. Pero no existe ninguna forma de limpiar...
Se te ocurre algo...
Es algo urgente. Aunque supongo que todo el mundo dice lo mismo.
Pero se me han acabado las ideas...
1 respuesta
Respuesta de xavi -ae soft-
1
No se si te entendí, pero me temo que estas utilizando tablas temporales para almacenar la información que debes manipular y, una vez hecho eso, eliminarlas.
Si es así ya te habrás dado cuenta de que Access 'crece' para dar cabida a esos datos pero que, una vez eliminados, no se contrae para recuperar ese espacio. Para ello requieres de compactar la base de datos.
Pero resulta que tu estas llegando al limite (2 Gb) a medio proceso, con lo que no te sirve la táctica de compactar. Digo no te sirve porque esa táctica cierra la base de datos comprimiendola y tu necesitas que, al volver a abrirse, siga con el proceso.
¿Lo he entendido bien?
En función de la respuesta seguimos.
Si es así ya te habrás dado cuenta de que Access 'crece' para dar cabida a esos datos pero que, una vez eliminados, no se contrae para recuperar ese espacio. Para ello requieres de compactar la base de datos.
Pero resulta que tu estas llegando al limite (2 Gb) a medio proceso, con lo que no te sirve la táctica de compactar. Digo no te sirve porque esa táctica cierra la base de datos comprimiendola y tu necesitas que, al volver a abrirse, siga con el proceso.
¿Lo he entendido bien?
En función de la respuesta seguimos.
Exacto.
No podías haberlo entendido mejor...
No podías haberlo entendido mejor...
Si simplemente no sabes, dímelo. Pero di algo.
Mil disculpas por la demora, pero primero estuve muy ocupado y después estuve enfermo :-(
La verdad es que parece un problema un pelín complejo... porque tu bdd es, de por si, bastante pequeña (en comparación con el límite admisible), por lo que no creo que venga de esos 100 Mb.
La única solución que se me ocurre es dividir los procesos de forma que ninguno de ellos haga crecer la bdd tanto. A lo mejor incluso deberás acotar alguna de las consultas para que se ejecuten en 2 o más pasos. Por ejemplo acotar distintos rangos de fechas.
Es posible que, después de cada consulta, tuvieras que ejecutar una compresión de la base de datos.
Por otro lado siempre puede quedar la posibilidad de migrar a SQL... aunque ese comentario sobre ASP que has hecho no se si lo va a permitir (pero ahí debo reconocer mi ignorancia)
Xavi
La verdad es que parece un problema un pelín complejo... porque tu bdd es, de por si, bastante pequeña (en comparación con el límite admisible), por lo que no creo que venga de esos 100 Mb.
La única solución que se me ocurre es dividir los procesos de forma que ninguno de ellos haga crecer la bdd tanto. A lo mejor incluso deberás acotar alguna de las consultas para que se ejecuten en 2 o más pasos. Por ejemplo acotar distintos rangos de fechas.
Es posible que, después de cada consulta, tuvieras que ejecutar una compresión de la base de datos.
Por otro lado siempre puede quedar la posibilidad de migrar a SQL... aunque ese comentario sobre ASP que has hecho no se si lo va a permitir (pero ahí debo reconocer mi ignorancia)
Xavi
