Out Of Memory
 

Tengo un problema enorme. con CSV y Delphi.
Necesito cargar a SQLServer un archivo CSV delimitado por | (pipe) el cual tiene mas de 3 millones de registros con 20 campos, al llegar a 2,500,000 se para indicando "OUT OF MEMORY", leyendo algunos comentan que por que esto se debe al limite de los archivo de texto que no pueden tener mas de "X" cantidad de filas, la verdad ya no se cual es el problema, si el tamaño del archivo txt o al insertar los datos.


Se preguntaran por que no cargo directo???, antes de insertar tengo que procesar la información y después insertar, razón pro la cual no puede ser directo, he leído que el problema se puede resolver usando FileStream, pero no tengo idea de como implementarlo.

Alguien tiene idea de como resuelvo mi problema y cual es el problema.

El archivo lo estoy leyendo con un
f: textfile;

Código Delphi [-]
Procedure ......
.
.
.

  assignfile(f, 'c:\list\p1.txt');
  reset(f);
  Size := FileSize(f);

  sgItem := TStringList.Create;
  StringGrid1.RowCount := 2;

  while not eof(f) do
  begin
     assignfile(f, 'c:\list\p1.txt');
     reset(f);
     Size := FileSize(f);

     while not eof(f) do
     begin
        readln(f, temp);
        CsvNombre := copy(temp, 1, pos('|', temp) - 1);
        delete(temp, 1, pos('|', temp));
        CsvSexo:= copy(temp, 1, pos('|', temp) - 1);
        delete(temp, 1, pos('|', temp));

           ...
             // se hacen operaciones con los valores para despues insertarlos
           ...
           with ADOQuery2 do
           begin
              SQL.Clear;
              xSQL:=' insert into dbo.datos (NOMBRES,SEXO)';
              xSQL:=xSQL+' VALUES ('''+xc1+''','''+xc2+''')';
              Memo1.Text:=xSQL;
              Memo1.Refresh;
              SQL.Add(xSQL);
              ExecSQL;
           end;
      End;
   End;
..
.
.

End;

¿Porque no procesas el archivo por partes ?
Divide y vencerás.

Proba con un TStrings.

Por ejemplo, la clase TStringList te provee el metodo LoadFromFile y luego vas recorriendo la propiedad Items que representa una lista de strings

Despues, dado que tu archivo viene separado por un caracter especial, deberias investigar sobre DelimiterChar y DelimitedText

Revisa este enlace y este otro

Respecto al comentario de dividir el archivo, estoy de acuerdo seria lo mas fácil pero no es la solución.

A manera de comentario, he seguido leyendo y algunos comentan que puede deberse al ADOQuery que uso para insertar lo registros procesados que tuvieron alguna alteración.

Ahora bien, pensaran por que no cargar la tabla a SQLServer y después se procesa!!!! pues bien, dado que la tabla tiene mas de 3 Mdr de registros el hacer el Select * from dbo.tabla me implica que tarda bastante en seleccionar los registros y después procesar, no omito aclarar que esto tambien me marca OUT OF MEMORY procesando menos de 1MdR.

MMmm se me ocurre una solución pero la voy a dejar como ultima alternativa.

Disculpa la ignorancia, pero ¿porque no sería una solucion?
Si realizas correctamente el procedimiento, por ejemplo parametrizando el numero de registros procesados por vez, te puede resultar para cualquier tamaño de archivo. Recuerda tambien que el procesar demasiadas operaciones en una sola transaccion es altamente ineficiente.

En realidad si seria una solución, pero no trabajando directamente el archivo CVS delimitado por PIPE, por que no tengo idea de como decirle que tome de X cantidad en X cantidad, pero si se puede desde SQLSERVER indicando que tome de Y registro a Y registro hasta terminar con todos los registros.

Pero si me diste la idea.

Tenes un doble while not eof anidados. No estaras procesando algo de mas? :D

No es necesario que abras el archivo entero en memoria. Podes leer de a una linea (busca sobre ReadLn)

1. Preparas el archivo para solo lectura.
2. Creas un ADOQuery, asignas la sentencia SQL y la dejas Prepared := True
2. Mientras no sea fin archivo, tomar una linea
3. Procesar linea, setear parametros ADOQuery, llamar a ADOQuery.ExecSQL
4. Vuelve a 2, cuando sea Eof := True, fin del proceso :)

Eso no puede gastar casi nada de memoria

El problema esta en otro lado, ademas de ese doble while anidado que no me gusta para nada (aun asi no te podria dar out of memory aunque fueran trillones de lineas, porque siempre procesas de a 1)

Yo creo que tu problema esta en el "se hacen operaciones con con los valores". Depura el codigo y busca memory leaks.

Añade la linea

Código Delphi [-]
ReportMemoryLeaksOnShutDown := True

Ejecuta tu proceso, y luego del Out of Memory, cierra la aplicacion e investiga donde estan las fugas de memoria

Hola,
todo apunta a que la iteración del fichero no la haces bien, como apunta AgustinOrtu.

Revisa esto lo primero.

Por otro lado, podría darse el caso ( después de corregir la iteración del fichero ) , que tengas que hacer cada x registros un commit. Esto lo sabrás cuando hagas bien la iteración.

Saludos

Independientemente de que puedas continuar con esta solución, tal vez puedas revisar otras alternativas.

Como alternativa, se me ocurre que pruebes a realizar la importación directamente desde SQL Server. Revisa los DTS. La idea sería algo así, por ejemplo . Eesto variará dependiendo de la versión de SQL Server.

En cuanto al proceso actual, yo también creo que tal vez deberías dividir el fichero. Pero no en la generación, sinó realizar un prepoceso del CSV para dividirlo por partes.

Gracias por sus comentarios.

Voy a revisar todo lo que indicaron para ver si se resuelve el problema de OUT OF MEMORY de lo contrario pues intentare la otra alternativa de seleccionar x cantidad en x cantidad.

Muchas gracias a todos.

1. Por favor, coloca completo el mensaje de "Out of memory"; es importante determinar "quien" está lanzando la excepción ya que puede ser la base de datos, el driver, el sistema operativo, etc.

2. Coincido con AgustinOrtu, en lugar de construir la sentencia sql de inserción mejor déjala preparada con parámetros. Eso no resuelve el problema pero obtendrás mejor desempeño.

3. Verifica si la llamada a el procedimiento está inmerso dentro de una "transacción SQL": tres millones de registros esperando un commit o rollback pueden "reventar" la aplicación por cualquier lado.

4. Para descartar, comenta el bloque de código with AdoQuery2 do begin ... end. Si el problema persiste la falla está en la lectura del archivo, si se corrige entonces el problema está en el acceso a la base de datos.