Hacer mascaras en consultas sql.
 

Buenos dias:

estoy haciendo una seleccion de unos proyectos hechos en mi aplicativo pero tengo una duda:

los datos que me imprime son algo asi:

lo que deseo es cambiar el 1 por Si y cambiar el 0 por No para los campos volumen y peso, es posible hacer el cambio visual solo en la seleccion sin modificar los datos de la base ???

Gracias, esta es mi consulta sql, uso interbase 6.

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

Desconozco si IB tiene algún tipo de condicional. En MySql, podrías hacer:

Código SQL [-]
select
  cod_proyecto,
  if(volumen = 1, 'SI', 'NO') as volumen,
  if(peso = 1, 'SI', 'NO') as peso
from
  transp_total

Mira a ver si IB tiene condicionales.

Otra opción es dejar la consulta como está y Utilizar el evento OnGetText del dataset para que muestre los valores que deseas.

// Saludos

Saludos

Tambien podrias probar con CASE

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

Ahi tienes para escoger, las dos son validas!

Gracias
 

Ya lo habia intentado hacer asi por simple intuicion pero no me habia funcionado por que no reconocia el if.

pues despues de leer tu mensaje enseguida me puse a buscar y encontre que no. Aqui :(

No lo estoy haciendo para usarlo en delphi, si no cuadrando el sql para despues pasarlo a Crystal SQL Design.

lo he intentado hacer asi pero me indica :

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

Gracias totales :)

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...

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

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


Saludos...

¡No inventes! :D

¿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

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...

Mmmm.. Hubiera jurado que substring era parte del standard.

// Saludos

Las funciones que soporta IB son: AVG, CAST, COUNT, EXTRACT, GEN_ID, MAX, MIN, SUM y UPPER. Esto lo saqué de la documentación de la versión 7.

La función substring no está soportada, y solo se puede hacer usando la UDF substr.




Saludos...

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

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

Te prometo que lo intentare :)

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.

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.
:p

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

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

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

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

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". :)