Access - Access me copa la memoria RAM

Muy buenos días. Mi nombre es Ricardo y unos de mis hobbies es la PC. Soy Ingeniero Mecánico asi que mis conocimientos en informática son bien limitados mas en teoría.

Mi participación en este foro ha sido buscando como aclarar la siguiente duda.

Estoy utilizando Access 2007 con una base de datos de algo mas de 800 Kb.

Mi PC tiene el W7 64 y 8 Gb de RAM. MI duda es por no entiender que ocurre que tiene que utilizar tal cantidad de memoria, que cuando hago una consulta (query) ,esta se me dispara a mas de 4 Gb utilizados.

Me parece insólito que utilice tanta memoria si la base de datos tiene menos de 1 Gb, eso por un lado, lo segundo es que sospecho que debido a eso pese a tener 8 Gb cuando trato de hacer un 2do query la PC se me queda ejecutando por un largo rato sin dar resultados o me arroja el error de que la consulta ha rebasado los 2 Gb que tiene Access para una base de datos (que por cierto no encuentro la manera que eso se pueda cambiar a una cantidad mayor).

¿Alguien sabría decirme que esta ocurriendo y como lo puedo solucionar?.

Muchas Gracias !!

Creo que el problema es la consulta. Tal vez las tablas que está usando no están bien relacionadas.

Puede que te falte relacionar algún campo, esto produce que la query comienza a probar TODAS las combinaciones de ese(esos) campo(s) que está(n) libre(s).

Esos casos son fáciles de detectar ya que el resultado de la consulta es extremadamente grande o la ejecución demora más de lo normal.

Revisa el modelo relacional de tus tablas.

Hola Marcelo. Muchas gracias por haberme contestado.

La verdad es que por mis escasos conocimientos te entiendo poco. No entiendo como es so de las tablas relacionadas por ej..

Yo lo que hago son básicamente dos consultas. Una de duplicados y la segunda de "no coincidentes".

Las dos se tardan algo como 10 mins. cada una pero se ejecutan. El problema se me plantea en la segunda ("no coincidentes"). Que extrañamente no me deja hacer nada porque se tranca. Por decirte que trato de dirigirme con la flechita al ultimo registro y se queda en consulta en ejecución y no termina nunca. Hasta que tengo que cerrar el Access a través del Administrador de Tareas.
Igual que no puedo ordenar una columna porque igual se tranca.

Lo de copar la memoria entiendo que sea porque tengo la consulta abierta. Y así una vez que la cierro baja el consumo pero para volverla a obtener debo ejecutar las consultas de nuevo. Es por eso que he tratado de hacer una tabla de la consulta pero igual se queda en ejecución y no termina nunca. Y si lo hace me sale el error que ha rebasado los 2 Gb de memoria de una base de datos o algo asi.

No se si me he explicado mejor.

Ojala y me puedas ayudar. No entiendo como siendo una tabla producto de la principal y si acaso algo mas de un 10% de la misma, ocurra que se tranca de esta manera sin dejarme trabajar.

Gracias !!!

Lo más probable es que sean las relaciones. Access y la mayoría de la BBDD funcionan con el modelo relacional, Este permite debe estar definido previamente antes de comenzar a trabajar con las Consultas y los otros objetos.

puedes googlear "Modelo Relacional en Access"

http://www.aulafacil.com/Access2/CursoAccess/Lecc-6-Acc.htm

Si quieres me puedes enviar un extracto de las tablas que estas usando para tus consultas y la consulta en un archivo de Access que no te funciona correctamente. Comprime la BBDD con WinRar y me la envias

Ok. Para no molestarte primero déjame probar googlear para las relaciones de Access que no tenia ni idea y si no lo logro te lo envió. Muchas Gracias !!

Hola!...

Acabo de leer tu mensaje, te comento, que lo ideal en las tablas de modelo relacional, es que tengas al menos dos campos como identificadores, al mismo tiempo que tus tablas tengan un identificador y quizás uno o dos campos más... Es más que nada, "pensar" de otra manera... Te explico:

La idea de todo esto, es que puedas decir, por ejemplo

"Busco la Pieza roja hecha en Paris por XYZ"

Y que la base de datos te devuelva UN resultado ( Que seguramente es el que buscas )en el menor tiempo posible, usando la menor cantidad de recursos, por ello, es que más arriba te sugerí "pensar" distinto

Entonces, lo ideal hacer 3 tablas... Piezas, Lugares y Fabricantes, para que al hacer la intersección entre los 3 elementos tu puedas encontrar lo que buscas rápidamente...


Espero esto ayude a aclarar tu duda
Un saludo!

Seria algo así, tengo 7 campos A,B,C,D,E,F y G. En los que me interesa saber coincidencias son el C,D,E y F, sin perder la relación con A, B y G. Así que lo que hago por ejemplo es hacer una consulta que solo me tome C y D otra E y F y otra A,B y G. Serian 3 tablas para completar los 7 campos (escribí 8 antes por equivocación). Ahora bien ¿como hago para que no se pierda la relación que tenían C y D con E y F; y, C, D, E y F con A, B y G?, será que en la misma consulta selecciono 3 tablas para extraer los datos 1. A.B,G 2- C,D y 3- E,F de la misma base de datos y al tiempo antes de realizar la consulta relaciono las 3?, ¿es algo así?, ¿será que entendí algo?. Nunca he hecho algo similar.

Para tratar de ilustrar que es lo que persigo, estoy tratando de hacer una consulta para buscar que elementos C y D se repiten, quiere decir los C y D que están mas de una vez (duplicados), luego para saber los únicos (que están una sola vez) hago una consulta de los C no coincidentes (Intersección) entre la original y los duplicados que obtuve en la primera consulta. Esta es la consulta que después de ejecutada no me deja hacer nada sin trancarse.

¿Será que haciéndolo como dices lo logro?

Lo otro es que no se porque me temo que la segunda consulta de no coincidentes no me dejará hacer ninguna tabla así que esta división en principio debo hacerla con la de arranque. La de base, la original, ¿no?.


¿Será que entendí algo?

P.S. En este momento no me encuentro en el sitio donde trabajo con esa BD.

Hola de nuevo!...

Es más o menos esa la idea, antes de seguir, te comento que por definición el diseño relacional que planeas, no te permitiría "ingresar duplicados"...

Por qué..? Simplemente porque existen dos claves iguales y eso no se permite...

Referido al diseño...

Dados todos los elementos que tienes (A;...;G )

Sería algo más o menos como

Tabla uno A,B,C
[identificadores de tabla= (A B) (AC) (BC), ]
Tabla dos D,E
[con un solo identificador, o bien D o bien E, o ambos, eso lo decides tu]
Tabla tres F,G
[idem tabla dos, pero con F o G]
Tabla cuatro (resumen)
[identificador de tabla= (un elemento de tabla 1 y otro de tabla 2 y otro de tabla 3) es sobre esta tabla que tu ejecutarás la consulta, ya que es mucho más fácil de recorrer y mucho menos "pesada "]

Entonces, ahi sí, no van a existir los duplicados, por definición de "clave"


Lo de la consulta que intentas hacer sería algo así como esto?
"[ (elementos de tabla uno (ABC) union tabla dos (DE) ) menos (elementos de C ) ]"


Espero esta breve explicación arroje luz sobre lo que intentas lograr

Saludos!

Listo. de vuelta a la PC con la BD en cuestión.

Pues bien creo que para entender bien de que se trata voy a poner un ejemplo lo mas real posible. Ya que creo que no me supe explicar por lo que me comentas de la consulta que quiero hacer como en segunda instancia y lo cierto es que lo que estoy haciendo es diseñando un método para obtener un resultado y las dos consultas forman parte de ese método. Una después de la otra.

Supongamos como creo eres español ;) el Corte Ingles, que tiene millones de clientes en quien sabe cuantos años de existencia y estos de alguna manera forman una base de datos enorme.

Supongamos para simplificar que esta base de datos consta de cuatro campos, A=código del cliente, B=Apellido, C=Nombre del Cliente, D=Monto de la compra

Lo que yo estoy tratando de conseguir son ventas ficticias realizadas por los empleados (una suposición) donde los Apellidos sean un invento, quiere decir no existieron en realidad. Por lo tanto no son comunes. Como ejemplo alguien que tenga de Apellido "Cachondo" lo mas seguro es que si lo usaron aparezca una sola vez para despistar y yo lo estoy tratando de ubicar.

Para ello lo que hago es una primera consulta buscando duplicados entre los Apellidos. Quiere decir que de esta forma los comunes los ubico dejándome afuera los que no se repiten nunca estando una sola vez, luego entonces para saber cuales son estos Apellidos únicos o extraños hago una segunda consulta buscando los "no coincidentes" entre la lista donde están todos los clientes de la tienda y la lista que me resultó de la consulta de duplicados. En palabras pobres resto la primera lista de la primera consulta(Apellidos duplicados). De esta forma estoy tratando de conseguir una lista donde quizás me aparezca Apellidos como "Chaval" o "Spiderman" o "HombreX" o quien sabe que disparate que trataré luego de someterlos a una investigación. No se si me explico. Y menos se si el método que estoy diseñando sea la mejor manera de obtener lo que quiero. Es lo que se me ocurre con lo poco que se de Access.

Entre paréntesis como he dicho, a la final logro con esfuerzo obtener esta resta de listas pero el problema es que por lo que me explicas y entiendo que debo relacionarlas de otra manera se le hace muy pesado al Access y no hay manera de seguir trabajando.

Claro está que la difícil tarea después seria descartar los Apellidos únicos que si pueden existir. Algún extranjero que haya comprado una sola vez por ejemplo. Pero esa es otra historia.

Y para serte sincero lo de los separadores, identificador y claves no entiendo como es que lo aplico porque puede que los conozca pero al ser mas empírico que teórico el lenguaje técnico me pierde.

Siguiendo tu ejemplo..

La base de datos consta de cuatro campos,
A=código del cliente, B=Apellido, C=Nombre del Cliente, D=Monto de la compra

Lo que intento decirte es que armes tablas de esta manera...

A,B,C = Tabla_I, con el identificador en (A,B,C) porque? porque pueden existir hermanos que compren en el mismo lugar...

A,D= Tabla_II, para mayor rapidez, como el identificador va a ser "A" y va a ser uno solo

Estando vinculadas ambas tablas por el código de cliente...

Respecto de la consulta...
Necesitarás utilizar el lenguaje propio de las bases de datos, que se conoce como
Lenguaje de Consulta Estructurada

( SQL, por sus siglas en inglés ) En SQL, tu consulta puede tener este aspecto....

SELECT // seleccionamos que campos vamos a elegir
cod_cliente
COUNT(*) // contamos la ocurrencia
FROM // desde que tabla vamos a contar los datos
(SELECT DISTINCT
cod_cliente,
apellido,

FROM
Tabla_I

)
Tabla_I
GROUP BY // agrupar por

cod_cliente,

HAVING COUNT(*) > 1 //aquellos que hayan sido cargados ( >1) vez

esta consulta debería devolverte los resultados, agrupados por código de cliente con una existencia superior a 1, es decir, como dije más arriba, hayan sido cargados más de una vez, si quieres, puedes cambiar el símbolo para que aparezcan solo aquellos que fueron puestos una sola vez es decir <2, en el HAVING COUNT, te daría solo aquellos que existen una sola vez en Tabla_I


Los separadores, lo hice para que veas que se hace como si fueran operaciones matemáticas, ya sabes, separas en términos y vas operando...

Identificador/clave= diriáse que es el campo con que va a estar índizada la tabla.


Espero esto sea de ayuda con tu consulta, tablas y BD.

Un saludo!

PD: Las dobles barras son comentarios para que te ubiques que son una especie de marcas del lenguaje, palabras reservadas /operaciones propias del lenguaje

Creo que hay algo que no debe ser. La columna A necesita solo 2 caracteres y cuando abro la vista diseño tiene 255. Lo mismo ocurre con la C,D,E y D que necesitan máximo 10 diría yo y tienen 255, esto quien sabe como he leído al ser millones de registros ponga pesada cualquier creación de tabla, ¿no?. Yo creía haber cambiado este número por un máximo de 20 pero ahora mismo tengo que ver como pasó porque en las opciones avanzadas del Access no la encuentro.

Que extraño....no me deja disminuir los campos a 50 que es de sobra. Me dice que no puede abrir la base de datos que puede que no la reconozca la aplicación o que el archivo esta dañado.

Luego que solucione esto ya he estado leyendo lo de la clave y los identificadores

Muchas gracias. Ahora lo que me toca es estudiar esa parte porque hasta ahora no he usado SQL para diseñar consultas. Lo único que he hecho es utilizar algunas de las herramientas de Access. Que para ser sincero en Abril de este año por primera vez comencé a descubrirlo. Yo solo he usado mucho Excel, bastante Word y algo de PowerPoint pero Access nada. Espero poder lograrlo.

Con respecto a los hermanos esta bien, si compran los dos en la primera consulta los toma como buenos porque están dos veces. La cuestión es que sean únicos. Y como dije lo difícil luego me tocará encontrar los que verdaderamente no pueden existir como Apellidos. Nadie se llama HijodeP por ej... :).

La columna A y D que son identificadores, no necesitan muchos "espacios" o sea como mucho serán 4 ciffras de clientes....

B y C son de tipo texto... Con lo que con mucho más de 30 espacios no necesitarás.
-Nadie tiene un nombre con más de 30 letras... es posible pero no común-
D es del tipo monetario... y dependiendo de cuanto planeas vender, en la parte de abajo puedes editar la cantidad y el formato de los campos.

Las tablas, editas... los campos desde la vista Diseño, guardas, cierras las tablas y vas a
"Editar Relaciones" Creas una nueva relación con los campos A y D enlazando las dos tablas, y eso seria todo en la creación de las tablas...

Eso es lo que digo, traté con 30 en B y C y A y D están como Números: Enteros largos y creo que esta bien. Pero el problema es que cuando le doy a ejecutar a la mitad me sale el error que coloque arriba y no hace los cambios. Bien extraño.

Si las tablas tienen valores asignados, es probable que no te deje, por lo que deberías probar con las tablas vacías, para que luego el control via campo identificador, se pueda ejecutar... y referido a que no te deje guardar los cambios, es cierto, está bien extraño, mi recomendación es que intentes usar una nueva tabla y luego agregar los valores manualmente...

Trataré. Muchas Gracias !!

Buenos días a todos.

Que tal Luciano, hoy lo primero que hice fue tratar de cambiarle los valores a los campos pero igual no resultó. Te explico, la base de datos que uso está en formato csv, esta la abro con el Access 2007. Luego lo que he hecho es cambiarle los valores a la tabla vinculada y no hubo problema, lo chequee y están cambiados, 5 para A y 30 para los demás. Luego lo que hice fue crear con una consulta una tabla idéntica. Me lo hizo también. Pero cual fue mi sorpresa que cuando la veo en "vista diseño" los valores están otra vez en 255. Los trato de cambiar como ayer y no me deja. Es bien extraño los puedo cambiar en la tabla origen (csv) y no los puedo cambiar en una copia. Después de pasar esto seguiré con la relación de tablas porque creo que ya es algo que no cuadra.

Saludos !

Como lei por ahí para poder cambiar el valor del campo escogiera Memo en vez de Texto, y asi probé con colocar en el campo A 5 en vez de 255 y cuando guardé empezó a ejecutar, pero estando como en la mitad me arroja el error de que no hay suficiente memoria o espacio en el Disco Duro y tengo como 4 Gb de RAM y como 20 Gb de DD, menos entiendo que ocurre, ¿alguien tendrá idea?.

También encontré las restricciones para cambiar el valor del campo en Access 2007 y tampoco dice algo que me pudiera estar bloqueando el cambio.

Gracias !!

Lo cierto es que ahora los campos en la tabla vinculada volvieron a 255 y no me fije antes pero sale un aviso que los cambios de propiedades etc. en una tabla vinculada solo se pueden hacer en la base de datos origen. ¿la CSV?. ¿Debo hacerlo con un software para para base de datos CSV?.

Ya desistí por ahora del cambio de valor de campo y estoy tratando de dividirlas para después relacionarlas pero me deja hacer la primera con A y G solamente, luego trato de hacer la segunda con solo A,B y C (faltando todavía D, E y F) y me dice que no puede abrir la base de datos o porque esta dañada o porque la aplicación no la reconoce . ¿Que es lo que definitivamente ocurrirá si pude crear una tabla con todos los campos (8) y ahora no me deja hacer una con 3?.

Un saludo !!

Bueno por si alguien mas quiere opinar dividi la base de datos en 3 tablas relacionadas, pero todo sigue igual, en la que obtengo como resultado no me deja hacer absolutamente nada.

Buenos días.

Quería agradecer a Luciano y Marcelo quienes me ayudaron con este problema, e informarles que hoy me puse a hacer nuevamente las divisiones de la base de datos para relacionarlas luego, y por el momento he logrado hacer consultas sin que el Access se me tranque.

Lo único que hice extraordinario fue que al momento de abrir la base de datos seleccioné una de las columnas para que la dejara por fuera. Y estoy trabajando con una de 3 columnas a la cual le ordené la columna A y ok, luego hice una actualización y ok, luego y busqué duplicados, y ok, por ultimo busqué "no coincidentes" y ok.

Ahora traté de crear una tabla con el resultado de duplicados y si me dio el error de haber superado el máximo de 2 Gb para una base de datos o no hay espacio temporal bla... bla... bla... .. Sigue siendo extraño pero ya es un avance.

Así que debo decir que con el método de dividir y relacionar logré avanzar.

Muchas gracias !!

P.S. Luego tendré que aclarar lo de no poder cambiar el valor de los campos (255) pero ya será motivo para abrir otro tema.

Hola Ricvantri!

No hay de que, un gusto el poder ayudarte....

Respecto de lo que quieres hacer al final de la consulta que escribes, espero haber entendido correctamente lo que deseas hacer...

Te diré que, quizás está de más, ( ya lo hicistes... ) quizás no lo tuvistes en cuenta, la tabla "destino" ( donde tu deseas volcar los datos, con los datos duplicados) debería tener la misma estructura que la de "origen" (desde donde haces la selección de filas con criterio)
También te diré que tengas en cuenta algunas cosillas cuando vayas a insertar desde "origen" a "destino":

*La tabla destino de la sentencia INSERT no puede aparecer en la cláusula FROM de la consulta o de ninguna subconsulta que ésta tenga.

*La consulta no puede ser la UNION de varias sentencias SELECT diferentes.

*El resultado de la consulta debe contener el mismo número de columnas que las indicadas para insertar y los tipos de datos deben ser compatibles columna a columna.

*Si no queremos asignar valores a todas las columnas entonces tenemos que indicar entre paréntesis la lista de columnas a rellenar después del nombre del destino.


El código asociado a esto es algo así como

INSERT INTO Tabla (Col1, Col2, .. )
SELECT Col1, Col2, ..
FROM TablaAux”

*A modo de ejemplo te dejo este código, por si acaso tienes o quieres agregar campos extras a la tabla
INSERT INTO TablaDestino (campo1,campo2, campo3)
SELECT campo1, campo2, ” AS campo3
FROM TablaOrigen
WHERE “Condicion”


Espero ayude con lo ultimo que expones.


Saludos!

Hola Luciano, muchas gracias por todos los consejos.

Pues fíjate, no se si sabrás que estoy como sintonizado en un canal y ahora si me cambian la frecuencia aunque me estén hablando quizás de lo mismo no entiendo :).

La verdad es que como me hablas de SQL y yo lo que hago es usar herramientas del Access no me entero de como están diseñadas. Así que honestamente no sabría decirte que es lo que uso con respecto al SELECT por ejemplo. Tendría que ver las consultas en SQL y no lo he hecho.

Yo me limito a abrir una base de datos (csv) y luego simplemente hacer consultas sencillas hasta cierto punto. La de duplicados la estoy haciendo con los Apellidos solamente. Quiere decir para que me busque repetidos en la columna de Apellidos. Luego entonces le resto estos repetidos con una consulta de "no coincidentes" a la base de datos original donde están todos. El resultado son todos los Apellidos que están una sola vez. Y de hecho logro ver los que caben en la pantalla y así es.

Sinceramente esta mañana escribí que había logrado dividir la base de datos y así fue. Hice una consulta solo con el código del cliente y el Apellido y me los extrajo sin problema. Entonces luego en la tabla de los Códigos y Apellidos hice una consulta para que me buscara los Apellidos repetidos y me la hizo sin problema y por último hice una consulta de "no coincidentes" para que restara de la principal los Apellidos estos duplicados (repetidos) y también lo hizo. Que la verdad es que sin dividir la base de datos también lo hacia. En lo que me equivoqué es en decir que había avanzado, porque resultó igual que antes que no puedo de ninguna manera efectuar absolutamente nada sin que la base de datos resultante (A - B) se tranque.

La verdad Luciano a mi parecer es algo muy extraño sin ninguna lógica ya que la tercera es mucho mas pequeña que la primera y además es resultado de la principal. Quiere decir que los registros derivan de la principal y esta trabaja. Puedo hacer consultas sin ningún problema (aunque lentas), siendo millones de registros. Unas diez veces mayor. La gran pregunta es entonces, ¿que es lo que ocurre para que esta tercera consulta se niegue a trabajar siendo solo una parte de la principal?.

Ojalá que haya sabido explicarme mejor.

Un saludo !