Funciones y CHECK

Esto es siempre así, no es un atributo exclusivo restriccion de check sino
de cualquier restricción de integridad, y además no me sorprende.
si pruebas esto en northwind
alter table customers alter column customerid nchar(6)
go
alter table orders alter column employeeid bigint
verás que también obtienes errores, no se puede modificar un campo que esta
en una restricción de integridad, igual que nose puede modificar una udf que
garantiza una restricción de integridad, si te fijas, la nueva
implementación podría dejar inconsistente por completo la integridad que
quiere garantizar. Me parece más que un problema un alivio, se que mis
programadores no me modificarán la función haciendo que mis datos queden
inconsistentes.

Saludos
Miguel egea
"AC" escribió en el mensaje
news:bqhhu1$7u4$

Buenos días/tardes,

Al inicio de este hilo he expuesto una limitación que he en contrado en
CONSTRAINT CHECK: si contiene una función de ususario, ésta no se puede
modificar. Obliga pues, a DROP, modificar la función y a volver a añadir
CONSTRAINT.

Esta era la exposición inicial. Algún comentario al respecto?

"Javier Loria" escribió en el mensaje
news:%
> Hola Jose:
> No sabes en cuantas formas estoy en desacuerdo. Tal vez te sirva la
> ayuda de MS, tomada de los BOL:
> => > La integridad de entidad debe ser siempre exigida en el nivel más bajo

por

> índices que formen parte de restricciones PRIMARY KEY y UNIQUE, o que se
> creen independientemente de las restricciones. La integridad de dominio
debe
> ser exigida mediante restricciones CHECK, y la integridad referencial

(RI)

> mediante restricciones FOREIGN KEY, siempre que sus características
> satisfagan las necesidades funcionales de la aplicación.
> => > Saludos,
>
> Javier Loria
> Costa Rica
> Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
> que pueda ser copiado y pegado al Query Analizer.
> La version de SQL y Service Pack tambien ayuda.
>
> Jose escribio:
> > Si te sirbe de ayuda, yo nunca uso CHECK para validar los
> > campos sino triggers, usando RAISERROR para retornar un
> > mensaje de error a la aplicación.
> >
> >>
> >> - Se crea una función de usuario, que retorna un entero.
> >> - Se crea en una tabla una restricción CHECK que usa la función
> >> anterior.
> >>
> >> - Posteriormente, al intentar modificar la función, se obtiene el
> >> mensaje: 'No se puede ALTER 'dbo.FU_ ... ' porque el
> > objeto 'CK_Tb_ ... ' le hace
> >> referencia'.
> >>
> >>
> >> La misma función se usa en procedures pero en este caso, si no se
> >> usa en CONSTRAINT, se puede modificar sin ninguna restricción.
> >>
> >> ¿Alguna información respecto a esta restricción?
> >> Parece que cuando una función tiene como dependencia una CONSTRAINT
> >> CHECK no se puede modificar.
> >>
> >> Gracias de antemano.
> >>
> >>
> >>
> >>
> >> .
>
>

Hola:
Si, disculpa, pero cuando vi el mensaje de Jose, casi me da un ataque.
En principio me parece "natural" que cuando utilices una funcion para
crear un CHECK esta funcion quede "ATADA" al Schema, desgraciadamente no
esta documentado este BINDING automatico.
En SQL siempre nos hemos metido en problemas cuando los objetos viven
independientes de los otros objetos, es por eso que es posible borrar una
tabla que tenga vistas o procedimientos almacenados que la emplen y estos
queden huerfanos. Es responsabilidad del desarrollador revisar dichas
dependencias, y cambiarlas.
En el caso de las funciones es mas serio porque quedan pegadas no solo a
la interfase sino al codigo interno. Immagina el siguiente escenario: Creas
una funcion que toma un numero y devuelve 0 si es par 1 si es impar, Creas
una tabla con un CHECK basado en esta funcion=0 o sea aceptas solo pares;
agregas datos a la tabla, y luego decides que quieres cambiar la funcion por
el contrario devuelve 1 si es par 0 si es impar!!!. El SQL NO deberia
dejarte cambiar la funcion, ni siquiera con un ALTER. Los problemas de
logica que significaria hacerlo son demasiado complejos. La solucion como
bien lo dice Miguel es que el desarrollador expresamente elimine el CHECK,
altere la funcion y vuelva a crear el CHECK. Es como usar el cinturon de
seguridad en el carro, incomodo si, pero necesario :)
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.



AC escribio:

Buenos días/tardes,

Al inicio de este hilo he expuesto una limitación que he en contrado
en CONSTRAINT CHECK: si contiene una función de ususario, ésta no se
puede modificar. Obliga pues, a DROP, modificar la función y a volver
a añadir CONSTRAINT.

Esta era la exposición inicial. Algún comentario al respecto?

"Javier Loria" escribió en el mensaje
news:%

Hola Jose:
No sabes en cuantas formas estoy en desacuerdo. Tal vez te sirva
la ayuda de MS, tomada de los BOL:
=>> La integridad de entidad debe ser siempre exigida en el nivel más
bajo por índices que formen parte de restricciones PRIMARY KEY y
UNIQUE, o que se creen independientemente de las restricciones. La
integridad de dominio debe ser exigida mediante restricciones CHECK,
y la integridad referencial (RI) mediante restricciones FOREIGN KEY,
siempre que sus características satisfagan las necesidades
funcionales de la aplicación. =>> Saludos,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Jose escribio:

Si te sirbe de ayuda, yo nunca uso CHECK para validar los
campos sino triggers, usando RAISERROR para retornar un
mensaje de error a la aplicación.

- Se crea una función de usuario, que retorna un entero.
- Se crea en una tabla una restricción CHECK que usa la función
anterior.

- Posteriormente, al intentar modificar la función, se obtiene el
mensaje: 'No se puede ALTER 'dbo.FU_ ... ' porque el

objeto 'CK_Tb_ ... ' le hace

referencia'.


La misma función se usa en procedures pero en este caso, si no se
usa en CONSTRAINT, se puede modificar sin ninguna restricción.

¿Alguna información respecto a esta restricción?
Parece que cuando una función tiene como dependencia una CONSTRAINT
CHECK no se puede modificar.

Gracias de antemano.




.