Funciones y CHECK

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.




.

La columna tiene una restricción check sobre esa función, puedes hacer un
alter table y eliminar la restricción, modificar la función y volver a crear
la restriccio´n


Saludos

Miguel Egea
Microsoft SQL-SERVER MVP
Brigada Anti-Cursores
"AC" escribió en el mensaje
news:bqf7fs$lq$

- 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 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 jose!! seria bueno q expliques los argumentos de usar los triggers como
estas indicando!! ya que lo q dice Javier seria lo correcto, pero porque no
escuchar porque realmente lo haces?
Asi lo podemos discutir no te parece?

Maximiliano Damian Accotto
"Jose" escribió en el mensaje
news:071701c3b7fd$4eae4ac0$
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.




.

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