Insertar nuevo registro en firebird sin meter todos los campos

[anubis]

Hola,
La verdad no sabía como titular el título, valga la redundancia, pero me gustaría saber si es posible hacer lo siguiente:

En un sistema remoto con firebird, para evitar que los datos no demoren, lo que hago es hacer

Código SQL [-]
select numcheque from cheques where numcheque = 1

Con eso me saca solo los registros que tengan la clave = 1, el problema es que si hago

Código SQL [-]
select numcheque, factura from cheques where numcheque = 1

Me saca el numcheque y la factura, donde factura son campos blob donde estan guardados formato pdf, en algunos casos son algo grandes por tamaño y, si el cheque contiene varias facturas demora bastante en sacar todos las facturas.

Lo que yo quisiera es insertar un nuevo registro para añadir una nueva factura (campo blob) a un cheque evitando traerme todos las facturas de ese cheque.



Se que me complico mucho a la hora de expresarme perdonen ustedes.

gracias

[[AgustinOrtu]]

No entiendo cual es el problema

Código Delphi [-]
with AlgunObjetoQuery do
begin
  SQL.Text := ' INSERT INTO LaTabla (numcheque, factura) VALUES (:numcheque, :factura) ';
  ParamByName('numcheque').AsIntreger := NumeroChequeNuevo;
  ParamByName('factura').AsBlob := ? // ni idea, nunca use campos blob, pero supongo que esto ya lo sabes no?
  ExecSQL;
end;

Algo asi no te funciona?

Porque te tenes que traer todas las facturas?

[Neftali [Germán.Estévez]]

¿Exactamente qué es lo que estás intentando hacer originalmente y cual es el problema?
¿El problema es que obtienes más facturas de la cuenta? ¿porqué no obtienes sólo la que necesitas?

Por lo que he entendido (que no es mucho) tal vez tengas la definición de la tabla mal, por lo tanto antes de buscar otras soluciones, tal vez tengas que arreglar eso.

No entiendo...

Empezado por anubis

Con eso me saca solo los registros que tengan la clave = 1, el problema es que si hago

=> Si es el campo clave, sólo te debería sacar 1, para eso es "clave". ¿No hay clave primaria?

Empezado por anubis

...Me saca el numcheque y la factura, donde factura son campos blob donde estan guardados formato pdf, en algunos casos son algo grandes por tamaño y, si el cheque contiene varias facturas demora bastante en sacar todos las facturas.

=> Si sólo quieres 1 factura porqué te las traes todas. Pide sólo la que necesitas.
=>Me da la impresión de que las facturas (si es relación 1..N con cheques) deberías estar en otra tabla.

[ecfisa]

Hola anubis

Empezado por anubis

...
Lo que yo quisiera es insertar un nuevo registro para añadir una nueva factura (campo blob) a un cheque evitando traerme todos las facturas de ese cheque.

Yo tampoco veo el problema, si se trata de una inserción, no hay necesidad de traer ningúna columna (campo). Se procede a insertar los datos en una nueva fila como en el ejemplo que te puso AgustinOrtu.

Saludos

[anubis]

Gracias a todos,

Funcionar funciona perfecto como dice AgustinOrtu . gracias.

Respecto a los campos blob, quiza no se deban usar, la verdad no lo sabia, pero tengo que usarlos para almacenar las facturas y poder traerlas de forma remota cuando se necesitan. Si bien es cierto que cada factura puede tener un tamaño en pdf diferente en cada caso, quiza me podais decir el por qué no se deba usar aunque imagino que en algun momento me pueda corromper la base de datos al no tener un tamaño definido el campo.

Para guardar un factura lo que hago es lo siguiente y usando tambien lo que puso el amigo AgustinOrtu.

Código Delphi [-]
var
  campoblob:tstream;
begin
campoblob:=tfilestream.create(opendialog1.filename,fmopenread);
with AlgunObjetoQuery do begin   
  SQL.Text := ' INSERT INTO LaTabla (numcheque, factura) VALUES (:numcheque, :factura) ';   
  ParamByName('numcheque').AsIntreger := NumeroChequeNuevo;   
  ParamByName('factura').AsBlob := loadfromstream(campoblob,ftblob); 
  // ni idea, nunca use campos blob, pero supongo que esto ya lo sabes no?   
  ExecSQL; 
end;

Gracias de nuevo

[[AgustinOrtu]]

Yo sigo sin entender el problema

La verdad es la primera vez que escucho que los campos blob pueden causar corrupción. De eso la verdad no tengo idea, nunca he trabajado con blob y mientras así sea mejor

No es posible guardar en un campo texto la ubicación del PDF? De esa forma con el select sql en lugar de traer el PDF en si te traes una simple columna de texto y ya si el usuario desea verla bueno ahí la cargas y listo

[anubis]

No se si dan corrupción o cual seria el problema, lo vi por algún lado q no se debían usar campos blob. Lo de la dirección lo tengo q Checar porque tengo subír los archivos al servidor entonces.

[[Lepe]]

Yo antes no usaba campos blob (no puedes buscar en su interior, pesan más, etc), optaba por guardarlos fuera de la BBDD, pero eso también tiene sus inconvenientes (alguien puede borrar el archivo, debes compartir la carpeta de facturas en la red para que sean accesibles a todos los puestos, con la inseguridad que genera; las copias de seguridad tienes que incluir más archivos, etc).

Para eficiencia no hay problema con los campos Blob, porque cuando haces un select, lo único que se trae es el ID del campo Blob (es decir, no se trae el contenido del campo). Firebird guarda el contenido del campo en otra página de la Base de datos, solo se accede cuando fuerzas la lectura del contenido (por eso la mayoría de grids te ponen el texto (blob), para no realizar la búsqueda.

Por supuesto la BBDD pesará mucho más, por los campos blob, pero si tu aplicación los necesita, al final el espacio se ocupa igual (BBDD + ficheros).

A remarcar que se puede partir el archivo de BBDD llegado cierto tamaño (se especifica al crear la BBDD y ya Firebird se ocupa del resto), aunque si no usarás FAT (con su límite de 4 GB) y el disco duro es de 1 TB, pues quizás ni tengas que valorarlo.


Si los campos blob están definidos como subtipo texto, desde Firebird 2.0 puedes hacer un select buscando en su interior, algo tipo:

Código SQL [-]
select campoBlob where campoBlob containing 'pepe'

Firebird ya hace el moldeo de tipos de Blob a string automáticamente.

Si son binarios (como los pdf), tienes que andar con loadfromstream, savetoStream y Assign (no hay drama).

Cargar en un campo desde Archivo (el control de errores lía un poco el código... pero en realidad solo son 3 líneas):

Código Delphi [-]
procedure cargaFicheroEnCampo( fichero : TFilename; campo : TField );
var
  fs: TFileStream;
begin 
  if not fileExists(fichero) then raise exception.Create(Format( 'el fichero %s no Existe', fichero ));
  fs := TFileStream.Create(fichero, fmOpenRead) ; // el segundo parámetro consulta la ayuda.
  try 
    try 
        campo.loadFromStream(fs)
    except:
        ShowMessage(' Error al leer del fichero');
        raise ; 
    end;
    guardar la tabla que pertenece el campo!!  
  finally
    fs.Free; 
  end;
end;

Si el archivo es una foto y lo tienes en un TImage, en Image1.Picture tienes el SaveToStream y LoadFromStream

Y si necesitas cargarlo en memoria, para después transferirlo, usas un TMemoryStream:

Código Delphi [-]
var 
  fm : TMemoryStrem; 
begin
  fm := TMemoryStream.Create;
  image1.Picture.SaveToStream(fm);
  tabla1CampoBlob.LoadFromStream(fm);  //  campo persistente en el dataset correspondiente.
  tabla1.Post; 
  fm.free;
end;

Si un fichero es texto plano, tienes el TStringStream, todos son desdendientes de TStream y funcionan igual.

Saludos!

[[RONPABLO]]

Yo aun no entiendo que es lo que pretende hacer con:

Lo que yo quisiera es insertar un nuevo registro para añadir una nueva factura (campo blob) a un cheque evitando traerme todos las facturas de ese cheque.

osea, no entiendo que pretende hacer, de pronto podría explicar un poco más a ver si captamos la idea.


Por otro lado como te dijo Lepe al hacer la consulta que trae el campo blob en realidad estas treyendo algo así como una máscara con un texto que dice blob, el proceso de cargar el pdf no se ejecuta en una sentencia similar a:

Código SQL [-]
select numcheque, factura from cheques where numcheque = 1

así que no tendrás problemas de velocidad por hacer dicho query.

Pero ya que vas a guardar archivos pdf en la bd podría ser mejor que lo tengas en una base dados diferente por motivos prácticos, por ejemplo si dejas los archivos blob en la misma base datos donde guardas el resto de información está crecerá mucho, trayendo como gran inconveniente una demora cada vez mayor a la hora de hacer copias de seguridad, yo llegue a tener una base de datos con imágenes que pesaba 30G (documentos escaneados de varios años de un archivo, y obviamnete no estaba formateado el equipo en fat32 si no en NTFS), hacer una copia de seguridad de un archivo que pesa 300M es demorado, imagina 1G, 2G o 30G, es caótico si alguien lo hace manualmente, puedes programar una rutina para generar periódicamente una copia de seguridad pero ocurre que ahora tendrás otro gran problema los pdf (o lo que tengas en el archivo blob) tal vez no sea lo que más se guarde en la base de datos (pero si lo que más ocupa en espacio) así que por seguridad podrías querer tener copia diaria del resto de la información, pero de los pdf se puede tomar el riesgo de no tener una copia en digamos unos 8 días, al tenerlo en la misma bd no podrás definir si hacer esto o no, siempre tendrás que hacer copia de todo con el consiguiente gasto de espacio en disco duro, en pocas semanas ya tendrás lleno cualquier disco duro.

En fin espero sirva de algo estos comentarios.

[anubis]

Se agradece la la, información a todos .
La realidad es q la base de datos se creó en un principio de forma local, y se fueron añadiendo cosas en la medida q hacían falta. No contemplen su momento detalles como almacenar los blob en otra base datos porque a fin de cuentas estaba en local y era para mi uso personal. Con el tiempo esa base de datos y el programa se pasó a otras empresas y se almacén en un servidor para acceso vía remota con el consiguiente problema de la velocidad en datos cosa, q gracias a vosotros, he conseguido acelerar sustancialmente (nose si el pedir 18 registros sin blob de 8 campos el q tarde 6 u 8 segundos sigue siendo mucho). Los campos blob los traigo de uno en uno en base a las necesidades del usuario para q no se, ralentice la descarga, aunque algunos usuarios quieren descargarse las facturas y xml por mes (ahí si hay un problema, por lo tardado decir leyendo registro por registro del mes y descargando en una carpeta cada factura y xml, pero no se puede hacer más tendrán q, esperar. .
También contempló la posibilidad de comprimir los archivos antes de guardarlos en blob pero los pdf no tienen mucha compresión, al menos con las utilidades q he visto.
Y, respecto a lo q comentas ronpablo, al hacer

Código SQL [-]
 select * frontal facturas

no se entonces q trae entonces pero si tarda mucho, y si quito el traerse la factura tarda mucho menos.
Desgraciadamente, al estar todo el sistema instalado en varios sitios creo q es un poco complejo sacar la tabla de facturas y pasarla a otra bd, o si es fácil?. Lo voy a Checar. Lo q no quería, era, rehacer el programa que por cierto, lo hice para mi trabajo personal y ni espero q me lo paguen porque nunca, fue encargado.

[[RONPABLO]]

Empezado por anubis

Se agradece la la, información a todos .
La realidad es q la base de datos se creó en un principio de forma local, y se fueron añadiendo cosas en la medida q hacían falta. No contemplen su momento detalles como almacenar los blob en otra base datos porque a fin de cuentas estaba en local y era para mi uso personal. Con el tiempo esa base de datos y el programa se pasó a otras empresas y se almacén en un servidor para acceso vía remota con el consiguiente problema de la velocidad en datos cosa, q gracias a vosotros, he conseguido acelerar sustancialmente (nose si el pedir 18 registros sin blob de 8 campos el q tarde 6 u 8 segundos sigue siendo mucho). Los campos blob los traigo de uno en uno en base a las necesidades del usuario para q no se, ralentice la descarga, aunque algunos usuarios quieren descargarse las facturas y xml por mes (ahí si hay un problema, por lo tardado decir leyendo registro por registro del mes y descargando en una carpeta cada factura y xml, pero no se puede hacer más tendrán q, esperar. .
También contempló la posibilidad de comprimir los archivos antes de guardarlos en blob pero los pdf no tienen mucha compresión, al menos con las utilidades q he visto.
Y, respecto a lo q comentas ronpablo, al hacer

Código SQL [-]
 select * frontal facturas

no se entonces q trae entonces pero si tarda mucho, y si quito el traerse la factura tarda mucho menos.
Desgraciadamente, al estar todo el sistema instalado en varios sitios creo q es un poco complejo sacar la tabla de facturas y pasarla a otra bd, o si es fácil?. Lo voy a Checar. Lo q no quería, era, rehacer el programa que por cierto, lo hice para mi trabajo personal y ni espero q me lo paguen porque nunca, fue encargado.

Bueno un DataSet vía web no es muy optimo (de pronto trabajar por medio de los clientDataSet pueda ser mejor, pero no lo puedo asegurar), entre menos campos llames va a ir un poco mejor aun así será muy lento comparado con por ejemplo traer la información al computador por medio de un servicio web, pero toda esta optimización necesita cierto trabajo que solo depende de tu disponibilidad, al igual que separar la base de datos, acoplarse a traer la información por medio de un servicios web o por medio de archivos cgi o cualquier otro método que ayude a optimizar tomará algo de aprendizaje trabajo y de tiempo