Hacer mascaras en consultas sql.

[el_barto]

Empezado por vtdeleon

Saludos

Código SQL [-]
select
cod_proyecto,
Case volumen when
1 then 'SI'
Else
'NO'
End,
Case peso when
1 then 'SI'
Else 
'NO'
End
from
transp_total

lo he intentado hacer asi pero me indica :

Token unknown - line 3, char 12
when

[el_barto]

No lo pude hacer desde ib asi que hice mi reporte normal pero le inserte la siguiente formula y listo me quedo hecho:

IIF ({Query.PESO} = 1,'Si','No')

Gracias totales

[[maeyanes]]

Puedes probar mediante un store procedure...

Código SQL [-]
create procedure sp_transp_total
returns (
  cod_proyecto integer, /* o varchar(n) */
  volumen char(2),
  peso char(2))
as
  declare variable volumen_int integer;
  declare variable peso_int integer;
begin
  for
    select cod_proyecto, volumen, peso from transp_total into
      :cod_proyecto, :volumen_int, : peso_int; /* El : y peso no llevan espacio */
  do
  begin
    if (volumen_int == 1) then
      volumen = 'SI';
    else
      volumen = 'NO';
    if (peso_int == 1) then
      peso = 'SI';
    else
      peso = 'NO';
    suspend;
  end
end^

Y este ya lo puedes usar:

Código SQL [-]
select cod_proyecto, volumen, peso from sp_transp_total

Saludos...

[roman]

Algo complicado ¿no? A veces me sorprende la facilidad con que algunas cosas se pueden hacer en MySql.

Va otra opción, quizá ésta sí funcione en IB:

Código SQL [-]
select
  cod_proyecto,
  substring('SINO', 2*volumen + 1, 2) as volumen,
  substring('SINO', 2*peso + 1, 2) as peso
from
  transp_total

// Saludos

[[maeyanes]]

Esa también es otra opción, solo que requiere que se agregue la UDF substring a la base de datos...


Saludos...

[roman]

¡No inventes!

¿Por qué es tan complicado IB? Je, je, bueno, sería ridículo de mi parte ponerme a criticar IB pero me gustaría entender la filosofía que hay detrás. ¿Por qué funciones tan elementales (según yo) no vienen por defecto en el lenguaje?

// Saludos

[[maeyanes]]

Pues quien sabe... es algo que hasta ahora todavía no entiendo... Tal vez es así para apegarse lo más posible al estándar SQL92, no se, podría ser cualquier cosa... jejeje



Saludos...

[el_barto]

store procedure perfect ¡¡¡¡ lo probe mas no lo implemente en mi reporte dado que como lo explique anteriormente es muy facil desde crystal reports, y como dice roman para que complicarce si existen maneras mas sencillas para solucionar mi caso, claro, un store procedure podria ser mas optimo para otros casos

[[maeyanes]]

Prueba la consulta que hace uso de la UDF, es más simple de implementar... jejeje

[el_barto]

Te prometo que lo intentare

[roman]

el_barto

De tu último mensaje eliminé la cita al código de maeyanes. Te pido que no cites mensajes completos, hace más difícil la lectura.

[cuburu]

Empezado por el_barto

store procedure perfect ¡¡¡¡ lo probe mas no lo implemente en mi reporte dado que como lo explique anteriormente es muy facil desde crystal reports, y como dice roman para que complicarce si existen maneras mas sencillas para solucionar mi caso, claro, un store procedure podria ser mas optimo para otros casos

Pues yo pienso que si puedes dejar todo el trabajo pesado a la BD y programas lo minimo indispensable es mejor.

Cuando manejas esta clase de condiciones por medio de Store Procedures, Views o cualquer caso y que la BD puede hacerlo, es mejor dejarselo a ella.

La respuesta que doy es muy simple.

Qué pasaria si de repente te dicen que necesita hacerse una reestructuración de todo el programa o se necesita hacer otra aplicación en un lenguaje diferente para trabajar los mismos datos en la misma BD. Pues ya no tendrías que volver a codificar este tipo de operaciones en la otra aplicación pues ya las tienes dentro de la misma BD. Solo tendrías que llamarlas.

Ademas, cuando se trabaja con grandes volumenes de información, es mejor dejar todo el asunto de integridad referencial, updates, commits, rollbacks y todas esas cosas a la BD y no tratar de controlarlas desde nuestra aplicación..... despues de todo, para que un negocio funcione cada quien debe de hacer su trabajo, y si la BD nos puede ahorrar dolores de cabeza tratando de contener posibles errores en la BD pues hagamoslo.

[roman]

Empezado por cuburu

Pues yo pienso que si puedes dejar todo el trabajo pesado a la BD y programas lo minimo indispensable es mejor.

Al César lo que es del César...

Trabajo pesado habrá de ambos lados, aplicación y servidor.

Empezado por cuburu

Cuando manejas esta clase de condiciones por medio de Store Procedures, Views o cualquer caso y que la BD puede hacerlo, es mejor dejarselo a ella.

No sé si una UDF pueda considerarse parte del servidor, pero en el caso de MySql, las funciones mencionadas sí que lo son.

Empezado por cuburu

Qué pasaria si de repente te dicen que necesita hacerse una reestructuración de todo el programa o se necesita hacer otra aplicación en un lenguaje diferente para trabajar los mismos datos en la misma BD. Pues ya no tendrías que volver a codificar este tipo de operaciones en la otra aplicación pues ya las tienes dentro de la misma BD. Solo tendrías que llamarlas.

De acuerdo. Pero toma en cuenta que no todas las aplicaciones son susceptibles de cambios tan drásticos y hay que tener cuidado con "¿qué pasa si...?" pues puede uno terminar complicandose la vida por una supuesta futura necesidad. Trabajo en un sistema hecho sobre MySql, y ha funcionado bien durante más de tres años. Y aún cuando he pensado en la posibilidad de migrar a FireBird, mientras no lo haga, me siento cómodo con él y todas las funciones predefinidas que incluye; no las cambiaría en aras de una estandarización o hipotéticos reajustes futuros.

// Saludos

[cuburu]

En eso tienes toda la razón. Es incoherente tratar de controlar algo que no sabes si se va apresentar o no.

Quizas el error mio fue darle un enfoque basado en experiencia propia. Por lo regular trabajo con sistemas de esta indole y es más sencillo realizar este tipo de "maniobras".