Usar Varios IBQuery en un IBDatabase

[angel.sosa]

no puede adecuar tu respuesta Casimiro, pero tomando tu sugerencia, busque como resolverlo.
en realidad no pude hacer uso del método que la consulta es sumamente larga y mejor sustituí, las "." por "/". pues se me facilito de esta forma porque mi cosulta es bastante larga.

Código Delphi [-]
IBQuery1.SQL.Add('select LC.nombre_cliente, ...............................
IBQuery1.SQL.Add('ON CLI.cliente_id = C.cliente_id ');
IBQuery1.SQL.Add('inner join doctos_ve VE ');
IBQuery1.SQL.Add('on VE.cliente_id = cli.cliente_id  AND VE.fecha >='+Char(39)+(StringReplace(DateToStr(DateTimePicker1.Date),'/','.',[rfReplaceAll]))+Char(39)+' ');
IBQuery1.SQL.Add(' inner join condiciones_pago CPG ');
IBQuery1.SQL.Add('ON CPG.cond_pago_id = VE.cond_pago_id ');
IBQuery1.SQL.Add('inner JOIN vendedores ven ');
................................

perdon por no dar la solucion antes. andaba terminando el proyectito

[ecfisa]

Empezado por angel.sosa

no puede adecuar tu respuesta Casimiro...

Hola Angel.

Me alegra que hayas podido resolverlo y gracias por ponernos la solución.

Pero creo mas adecuado el modo que te sugirió Casimiro:

Código Delphi [-]
  with IBQuery1 do
  begin
    Close;
    SQL.Clear;
    SQL.Add('select LC.nombre_cliente, ...');
    SQL.Add('ON CLI.cliente_id = C.cliente_id ');
    SQL.Add('inner join doctos_ve VE ');
    SQL.Add('on VE.cliente_id = cli.cliente_id  AND VE.fecha >= :PFECHA');
    SQL.Add('inner join condiciones_pago CPG ');
    SQL.Add('ON CPG.cond_pago_id = VE.cond_pago_id ');
    SQL.Add('inner JOIN vendedores ven ');
    ParamByName('PFECHA').AsDate := DateTimePicker1.Date;
    Open;
  end;

Es mucho más seguro, entendible y menos propenso a equivocos.

Saludos.

[[Delphius]]

Empezado por ecfisa

Hola.

Y aunque lo creo innecesario, tambien podes:

IBDatabase1 <--+- IBTransaction1 <-- IBQuery1
               |
               +- IBTransaction2 <-- IBQuery2
               |
               +- IBTransaction3 <-- IBQuery3
               ...

Saludos.

Pues yo diría que esta opción es quizá más sana y segura para evitar conflictos sobre las transacciones. Por ejemplo, como cuando se tiene el error de que ya existe una transacción abierta.
Con esta forma uno puede dejar abierto varias transacciones individualmente en cuanto necesite. No está demás aclarar que tampoco es para dejarlas activas todo el tiempo, pero con esta manera si uno se es ordenado puede controlar mejor cada transacción posible de hacer en el sistema y tomar las acciones para el caso.
Pregunta: ¿Cómo le haces para detectar y discrimar cual de los tantos Datasets ligado a una única transacción es quien está en funciones y acaparando el uso de dicha transacción?

Saludos,

[Casimiro Notevi]

Empezado por Delphius

Pregunta: ¿Cómo le haces para detectar y discrimar cual de los tantos Datasets ligado a una única transacción es quien está en funciones y acaparando el uso de dicha transacción?

Código SQL [-]
ibquery3.transaction.commit;

[[Delphius]]

Empezado por Casimiro Notevi

Código SQL [-]
ibquery3.transaction.commit;

Se entiende que mi pregunta es cómo desde una transacción vas a distinguir cual de los datasets conectados a éste está es operación y haciendo uso del contexto. Se aprecia en tu código que estás haciendo lo opuesto, y lo que es peor, traspasando un mensaje por un intermedio y desobedeciendo la Ley de Demeter.
En términos reales y semánticos existen varias transacciones en una base de datos. Por tanto es natural y de esperarse que se requiera de mas de una transacción y no unicamente la de por “defecto“.

[Casimiro Notevi]

Que exista más de una transacción no tiene nada que ver con el número de 'componentes Transaction'

[[Delphius]]

Empezado por Casimiro Notevi

Que exista más de una transacción no tiene nada que ver con el número de 'componentes Transaction'

Oh... claro que si. Puesto que el componente no es más que la abstracción de éstas.
El IBTransaction lo que hace es determinar si está activa alguna transacción para operar, y sólo puede atender una a la vez. Por tanto con un único componente tu aplicación sólo puede atender de a una transacción por vez. Que gracias al poder del aislamiento el componente es capaz de escuchar si hay otras transacciones, no quiere decir que no tenga que ver, sino que es necesario de esto para determinar si es una operación válida. Pero he aquí que esta capacidad sale fuera del concepto ya del módulo de datos... sino que se hace al nivel propio de la base de datos.
Que pueda escucharlas, no quiere decir que las administre a todas. Sólo puede trabajar con una y de a una por vez.
Cuando se requiere de más de una transacción activa (y los correspondientes datasets) (que hay casos en los que se requiere) no puedes administrarlas, en tu aplicación y en la capa de datos, con un único componente.

En tu ejemplo, si efectivamente dispones de un único componente para las transacciones entonces tu código puede limpiarse mejor y no hacer esos pasos intermedios de ir desde alguno de los datasets. Basta con hacer simplemente:

Código Delphi [-]
MiTransaccion.Commit;

Como he dicho, ¿Dado un componente IBTransaction, cómo puedes saber que dataset está haciendo uso y solicitando una operación?

Bien dices que si tienes, y sabes, que la operación X pasa por el dataset Y entonces puedes controlar el flujo del programa de la forma:

Código Delphi [-]
MiDataSet.Algo;

Cuando estás en una apreciación inversa, en donde por necesidad hay posiblemente más de una transacción activa (que se puede hacer), ¿Cómo vas a controlar cuál transacción y que dataset en cuestión está actuando?
Velo con un ejemplo: se ha detectado un error y la práctica indica que debe capturarse la debida excepción y actuar en consecuencia. Generalmente, cuando el contexto lo amerita se lanza una nueva excepción con la información adecuada al contexto para la siguiente capa (se lo conoce, por si no lo sabes, como el patrón "Convertir excepciones" o "Abstracción de Excepciones") (1). Puede ser de interés por tanto saber ante un error de operación, (además de dicha operación) que combinación de transacción y conjunto de datos están involucrados. Esto ayuda a aislar el problema y poder encontrar una solución más pronto.

(1) Un ejemplo de ésto sería algo como: EDatabaseError >> EContableOperationException >> ELibroDiarioException. Donde la excepción se va elevando e incorporando información adicional para el contexto... Tal es así que al final una ELibroDiarioExcepcion sabe que una operación contable no pudo efectuarse debido a un error de base datos.

Saludos,