FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
Modificar Campo Calculado
Saludos.
He buscado en la ayuda y en el foro pero no he encontrado ningún tema de referencia. La tarea es poder modificar un campo calculado de una tabla ya existente (valga la redundancia) vía SQL. Hasta luego.
__________________
Gracias, Rolphy Reyes |
#2
|
|||
|
|||
Hola...
Te refieres a campos del tipo Computed en las tablas de una base de datos? O a campos calculados en un DataSet en Delphi? Saludos... |
#3
|
||||
|
||||
Saludos.
Cierto maeyanes por la prisa no especifique todos los datos, es para la base de datos y el motor es FB 1.5.
__________________
Gracias, Rolphy Reyes |
#4
|
|||
|
|||
Si un campo es calculado, me parece un absurdo querer modificarlo, habrá que modificar algunos de los campos que lo generran, no?
Saludos, |
#5
|
||||
|
||||
Saludos.
Cita:
La razón por la cual deseo modificar ese campo es porque justamente el "calculo" que realiza es incorrecto y ya esta en producción; esto no quiere decir que sus integrantes se estén guardando de manera errónea sino el cliente solicito el cambio y ellos son los que pagan. Hasta luego.
__________________
Gracias, Rolphy Reyes |
#6
|
|||
|
|||
Hola...
En ese caso puedes hacer lo siguiente; eliminar el campo y volverlo a crear con el cálculo correcto. Al ser un campo Computed este no guarda ningún tipo de dato, solo muestra el resultado del cálculo.
Saludos... |
#7
|
||||
|
||||
Solución del problema
Saludos.
Gracias maeyanes pero eso funcionaria sí y solo sí no tendrías referencias para el campo, pero en mi caso tengo unas quince (15) al mismo y esta en producción ya sabes el trabajo que eso implica. No obstante, para tratar de subsanar el fallido intento del ALTER TABLE al campo calculado decidí revisar la tabla RDB$FIELDS y en la misma encontré el campo RDB$COMPUTED_SOURCE, pensé aquí está mi salvación . Al cambiar el valor del campo y realizar un SELECT a la tabla veo que el valor continua igual, ahí mismo dije ya me j..... Vi un campo al lado llamado RDB$COMPUTED_BLR del siguiente tipo BLOB SUB_TYPE 2 SEGMENT SIZE 80 este me llamo la atención por la forma en que IBExpert lo visualiza (obviamente es un Blob) de diferentes maneras (Text, Hex, Picture, RTF, Web Page, BLR y Unicode Text) al ver su contenido me di cuenta de que este es el usado por Firebird para realizar la operación del COMPUTED BY (claro que al inicio pensé que era RDB$COMPUTED_SOURCE, pero al fallar el cambio). Contenido de un campo calculado visualizándolo como BLR: Cita:
Primero creo un campo temporal con el calculo que deseo
Segundo realizar el update del campo RDB$COMPUTED_BLR
Sí se fijan actualice el campo RDB$COMPUTED_SOURCE solo para mantener la referencia de que estoy calculando. Y por último
Espero que les pueda servir en algún momento. Hasta luego.
__________________
Gracias, Rolphy Reyes |
#8
|
|||
|
|||
Cita:
|
#9
|
||||
|
||||
Saludos.
Gracias Delfino pero cuando me refiero a que realiza mal el calculo es que la formula que tenía ya no funciona para el cliente, además de que estaba aclarando una respuesta que he habían dado. Hasta luego.
__________________
Gracias, Rolphy Reyes |
#10
|
|||
|
|||
Cita:
|
#11
|
||||
|
||||
Ingeniosa solución Rolphy, como para crear un SP utilitario llamado SPUpdateComputedField.
Nada más aclarar la diferencia entre un campo calculado (campo de memoria a nivel del programa) y uno computado (campo en la base de datos cuyo valor es el resultado de una instrucción SQL preestablecida). Saludos. Al. |
#12
|
||||
|
||||
Cita:
Por cierto, gracias por la aclaración.
__________________
Gracias, Rolphy Reyes |
#13
|
||||
|
||||
Nadie ha acotado que en este caso, el nuevo cálculo del citado campo solo será válido para los registros que se introduzcan posteriormente ya que tooooooodosss los registros que ya estaban en la base de datos ahora mostraron un resultado incorrecto.
Ejemplo de este efecto: El famoso IVA (en México del 15% sobre el subtotal de la factura). Si ponemos para más facil un campo calculado llamado IVA que sea igual a SUBTOTAL*0.15 funciona bien, y asi podemos capturar nuestras facturas sin mayor problema, peeeero....un buen día dicho impuesto cambia y ahora es de 16% (ni lo mande Dios). Como somos muy duchos vamos y cambiamos el campo calculado para que ahora haga SUBTOTAL*0.16 y ohhhhhh ya no cuadra nada de lo que teniamos previamente almacenado!!!!! ya que el nuevo cálculo es con 0.16 y lo que teniamos se dió por hecho que era por 0.15. Ojo: No utilicen campos calculados en valores que NO DEBEN VARIAR CON EL TIEMPO, es decir, valores que una vez capturados ya no se pueden modificar. En mi ejemplo el IVA de una factura es precisamente el que se cobró al momento de su elaboración y ningún otro. Es decir, no utilicen campos calculados si alguno de los valores involucrados es una "constante" al momento de hacer la operación. De esta forma, si podemos hacer un campo calculado para que nos saque el importe de una partida (CANTIDAD * PRECIO UNITARIO) ya que ambos datos ya no cambiarán una vez hecha la factura, es decir, tanto CANTIDAD como PRECIO UNITARIO son dos campos que se guardan en la tabla y ya no se veran afectados externamente.
__________________
AKA "El animalito" ||Cordobés a mucha honra|| |
Herramientas | Buscar en Tema |
Desplegado | |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Campo Calculado!!! | Ledian_Fdez | OOP | 1 | 03-10-2007 22:10:01 |
Pasar un campo calculado a un campo del mismo DbGrid | maravert | Conexión con bases de datos | 3 | 12-05-2006 00:31:30 |
Campo calculado | sercornejov | MySQL | 3 | 09-08-2005 02:54:35 |
Campo de bd calculado | davidgaldo | MS SQL Server | 3 | 20-05-2005 15:50:22 |
|