¿liberar memoria despues de usar una Query?

mrmanuel · #1 12-10-2005

Hola a todos.

Mi problema es la siguiente:

Estoy haciendo un listado sobre tabla DBase, usando sentencia SQL sobre una TQuery, cuando lleva evaluados 400 registros, me da un error de Memoria Insuficiente.
He medio resuelto el problema, poniendo un rango de busqueda de 300 registros cada vez, es decir del 1-300, del 300 al 600, etc.

El problema esta q los primeros 300 lo hace perfectamente, pero cuando le digo que liste el siguiente rango de 300, me vuelve a cascar con el problema de la Memoria. (Sigue siendo al evaluar el que hace 400).

He probado a poner:
Query.Free
Query.Sql.Free
despues de cada listado y en ambos casos, al intentar listar el segundo rango, que salta una excepción de Delphi.

¿Como podría liberar la memoria de una sentencia sql (Query), para cuando vuelva a usar dicha query este 100% libre?

Uso Delphi 5.

Gracias

[Lepe] · #2 12-10-2005

Pon el código para crear tu TQuery.

Si la creas en tiempo de diseño, solo tienes que cerrarla con query1.Close, modificar el query.sql.text y despues volverla a abrir.

saludos

lucasarts_18 · #3 12-10-2005

Cita:

Empezado por Lepe

Si la creas en tiempo de diseño, solo tienes que cerrarla con query1.Close
saludos

Una duda sobre esto, es decir el mismo formulario o contenedor se encarga de destruir el objeto ???

. Yo sospecho que así es..

lucasarts_18 · #4 12-10-2005

Hola:

Gracias a un Post de Roman, he leído que un Form al momento de destruirse llama automaticamente a un método DestroyComponents, esta es la respuesta..

Delfino · #5 12-10-2005

Aun asi conviene a lo mejor destruirla antes de cerrar el formulario..

[Lepe] · #6 12-10-2005

Cita:

Empezado por Delfino

Aun asi conviene a lo mejor destruirla antes de cerrar el formulario.

Me ha gustado esta respuesta. No deja claro si hay que destruirla o no, pero tampoco deja claro que no deba hacerse

.

La respuesta es: No hay que destruirla, es más ni siquiera cerrarla (query.Close), ya que al destruirse el contenedor, llama al destructor de la consulta, y si está abierta, primero se cierra y despues se destruye.

Gydba · #7 12-10-2005

Buenas gentes,

No se si viene de la mano del comentario de Delfino pero en mi caso siempre libero los objetos apenas dejo de utilizarlos así no siguen dando vueltas a lo largo de la vida útil de su owner.

Chauchas!!

ContraVeneno · #8 12-10-2005

espero que mrmanuel coloque su código para poder saber si le propongo que haga: TuQuery.SQL.Clear antes de usarla.

Delfino · #9 13-10-2005

Cita:

No hay que destruirla, es más ni siquiera cerrarla (query.Close)

Siempre pongo dataset.Close antes de cerrarse el form, eso pq he tenido varios problemas si no se llama al metodo close sobre todo cuando hay codigo en el evento datachange del datasource asociado, no se si ha pasado a otros.

Ademas segun este articulo es conveniente crear componentes con el owner nil y destruirlos..

mrmanuel · #10 21-10-2005

Hola a todos.

siento el retraso, pero problemas con el curro.

Bueno os comento. la Query la creo en tiempo de diseño, la cree simplemente añadiendola en una form, donde tengo una serie de tablas y de queris auxiliares.

Dicho form está activo en todo el momento, ya que desde el hago todas las operaciones de acceso a los datos. He probado a poner Query.Close, y nada.

respecto a lo de cerrar el form y que el se encarge de destruir los objetos, no lo puedo hacer ya que como he dicho antes, es el que lleva toda la chicha del programa.

he provado a liberar el la query en concreto, pero al intentar acceder a ella nuevamente, me dice que no, ya que le he liberado anteriormente y da problemas de acceso a memoria.

Lo que tendria que hacer es que liberarse la memoria usada para esa consulta, pero que no me cascase al intentar acceder a ella.

Gracias.

ContraVeneno · #11 21-10-2005

Código Delphi [-]with TuQuery do begin
 if Active then Close;
 SQL.Clear;
 SQL.Add('Select... etc');
 SQL.Add('From ... etc');
 SQL.Add('WHere.... etc');
 Open;
end; //with

a ver si eso te sirve...
al menos es lo que a mi me funciona y puedo cambiar el Query cuantas veces sea necesario....

mrmanuel · #12 10-11-2005

Hola nuevamente.

el codigo que me indica CntraVeneno, es tal y como yo lo hago, lo único que despues del OPEN, hago un Execute.

yo lo que quiero hacer es liberar la memoria q usa esa query en un momento dado, sobre tado cuando hago consultas con gran nº de registros.

el problema que tengo es q se me queda en memoria, creo, y cuando intento hacer cualquier tipo de consulta, ya sea en la misma query o en otra, me da error de acceso a memoria.

gracias

lucasarts_18 · #13 10-11-2005

Cita:

Empezado por mrmanuel

el codigo que me indica CntraVeneno, es tal y como yo lo hago, lo único que despues del OPEN, hago un Execute.

Execute por qué ?, bastaría con un Open si la consulta es un Select

Cita:

Empezado por mrmanuel

yo lo que quiero hacer es liberar la memoria q usa esa query en un momento dado, sobre tado cuando hago consultas con gran nº de registros.
el problema que tengo es q se me queda en memoria, creo, y cuando intento hacer cualquier tipo de consulta, ya sea en la misma query o en otra, me da error de acceso a memoria.

Si lo liberas y luegos deseas usarlo nuevamente, debes crearlo nuevamente..

Hasta Luego -

ContraVeneno · #14 10-11-2005

Cita:

Empezado por lucasarts_18

Execute por qué ?

si, ¿por qué?
Open cuando es consulta (Select)
Execute cuando es modificación (Update, Delete, Insert, alter, etc.)

¿nos podrías decir exactamente cuando haces que cosa te marca el error? y ¿cuál es el error específico que te marca?

[Lepe] · #15 10-11-2005

Si despues de 12 mensajes, no ha mostrado el código, será porque pertenece a MICROSOFT, fijo

.

saludos

lucasarts_18 · #16 10-11-2005

Cita:

Empezado por mrmanuel

el problema que tengo es q se me queda en memoria, creo

Asegurate con FreandNil(Objeto)

Cita:

Empezado por mrmanuel

y cuando intento hacer cualquier tipo de consulta, ya sea en la misma query

Aquí usas el mismo query, que al parecer ya has liberado y por lo tanto te da una excepción.

Cita:

Empezado por mrmanuel

o en otra, me da error de acceso a memoria.

Este seguramente no lo haz creado.

Cita:

Empezado por contraveneno

¿cuál es el error específico que te marca?

Es un error de los típico de numeros hexadecimales y cosas raras

Cita:

Empezado por lepe

Si despues de 12 mensajes, no ha mostrado el código, será porque pertenece a MICROSOFT

Hasta Luego -

[Lepe] · #17 10-11-2005

Cita:

Empezado por Delfino

Ademas segun este articulo es conveniente crear componentes con el owner nil y destruirlos..

A ver, a ver que son cosas distintas.... no podemos mezclar cosas, y si lo hacemos, debemos tener cuidado.

Si le ponemos a un objeto el Owner como Form1, Application etc, jamás llamaremos a Query1.Free en nuestro código, repito, jamás. ¿Por qué?, entendamos que significa Query1, que es lo mismo que cualquier otro objeto, ventana, clase de delphi, etc.

Query1 es una variable de tipo puntero. Si la ponemos en modo diseño, Delphi se encarga de crearla en memoria cuando se ejecute nuestro programa, y además el Owner de ese Query será el Form que lo contenga. Por tanto, cuando se libere esa ventana, se liberará el Query1.

Si en esa misma ventana colocamos un Query1.Free, la consulta se libera de memoria RAM, pero la variable Query1 se queda apuntando a la zona de memoria donde estaba creada. La próxima vez que se acceda a Query1 nos dará un access Violation. Es más, como ha sido puesta en modo diseño, al liberar la ventana, ésta intentará liberar la consulta, como Query1 es un puntero que tiene un valor, irá a esa zona para liberarla, y entonces obtendremos otro Access Violation.

Estamos en la situación de que un objeto tiene un Owner y queremos liberarlo de la memoria antes que su Owner, ¿no hay una solución? Si, usamos FreeAndNil(Query1); nosotros ponemos FreeAndnil(Query1), se libera la consulta de la RAM y además esa rutina hace Query1 := nil , y aquí está el truco; cuando se vaya a liberar el Form, éste pregunta ¿Query1 <> nil?, como es igual a nil, el Form entiende que ya ha sido liberado anteriormente y no trata de liberarlo de nuevo. No tendrá fallos nuestro código.

Otra situacións: Nosotros creamos un objeto y le decimos

variable := Tvariable.Create(nil);

es decir, no tiene Owner, por tanto, será mejor que nosotros la destruyamos. Para evitar errores en una segunda o tercera creación, tambien usaremos FreeAndNil(variable), si es nil, no ha sido creada previamente, o bien ha sido liberada. Si es distinto de nil, es que está creada, no debemos crearla de nuevo.

Si usamos variable.Free , variable se queda apuntando a una zona inválida de la memoria, por tanto, no sabemos si está creada, o ya fue liberada. Al usar FreeAndNil, no tenemos esa ambigüedad:

Código Delphi [-]Tform1 = class
private 
 query1:Tquery;
end;

procedure TForm1.Button1click(...);
begin
if query1 = nil then
  Query1 := Tquery.Create(nil)
else
  Showmessage('ya está creada')
end;

procedure TForm1.Button2click(...);
begin
  FreeandNil(query1);
end;

procedure TForm1.Button3click(...);
begin
  query1.Free
end;

Probemos a dar al boton1 y despues 2 o 3 veces al boton2, no ocurre nada ¿verdad?, el programa funciona bien.

Probemos a dar al boton1 y despues 2 veces al boton3.

Existe una situación algo más rara, es crear un componente en tiempo de ejecución y no liberarlo.

Query1 := Tquery.Create(form1);

Y nos olvidamos de FreeAndNil y de .Free, porque al fin y al cabo, le hemos puesto el dueño, él se encargará de destruirlo. Que es lo que hacemos con los TEdits, Grids, Buttons, que ponemos en nuestras ventanas en tiempo de diseño.

saludos y espero se entienda.

lucasarts_18 · #18 10-11-2005

Qué explicación lepe !!!!!!!
Con esto debería quedar más que claro este hilo

Hasta Luego -

[Lepe] · #19 10-11-2005

ups, pues lee de nuevo que lo he editado

saludos

vtdeleon · #20 10-11-2005

Saludos

No se si esto ya se ha dicho, he leido tanto este hilo que ya no sé de que se trata

mrmanuel
Muestranos el codigo que utilizas para:
Crear el Query,
Transaccion(un poquito)
y para liberarla.

Puede ser otra cosa que esté consumiendo