Asignar variables dentro de una función

¿Esta es la función que quieres?

CREATE FUNCTION RutaProyecto(
@IdProyecto int
) RETURNS varchar(8000)
AS
BEGIN
DECLARE @Ruta varchar(8000), @IdProyectoPadre int

SELECT @Ruta = NombreProyecto,
@IdProyectoPadre = IdProyectoPadre
FROM Proyectos
WHERE IdProyecto = @IdProyecto

WHILE @IdProyectoPadre IS NOT NULL
BEGIN
SELECT @Ruta = NombreProyecto + '\' + @Ruta,
@IdProyectoPadre = IdProyectoPadre
FROM Proyectos
WHERE IdProyecto = @IdProyectoPadre
END
RETURN @Ruta
END


Pero ¿para qué quieres esta función si el procedimiento almacenado
ObtenerSubarbolProyectos ya te la da?

Saludos:

Jesús López
www.solidq.com




"Mauricio" escribió en el mensaje
news:

Hola a todos,
tengo una función dentro de la cual tengo lo siguiente:

WHILE @parentId <> NULL
BEGIN
SELECT @id = @parentID
SELECT @parentID = IdPadre
FROM PROYECTOS
WHERE IdProyecto = @id

END
Dentro del loop tengo que asignar a una variable un campo de la tabla
proyectos, es decir que quiero hacer algo como:
SELECT @ruta = @ruta + ' ' + Nombre FROM PROYECTOS WHERE IdProyecto = @id.
Se puede hacer eso? Cómo?
Muchas gracias.

Mauricio
Copenhague, Dinamarca

Jesús,
cuando vi tu respuesta no pude dejar de reírme!!! No quise poner que
era esa la función que necesitaba para que no te sintieras obligado a
responderme (dado que ya me habías ayudado antes) pero lo adivinaste y
enviaste la respuesta exacta. Solo hice una modificación y es la
condición del WHILE, le puse WHILE @IdProyectoPadre <> 0 y me funcionó,
en realidad le estoy asignando 0 cuando no hay padre (tal vez un error
mío, lo sé).
Nuevamente: MUCHAS GRACIAS!!!!
Saludos.

Mauricio
Copenhague, Dinamarca

Tal vez sea un error asignar 0 cuando no hay padre y tal vez no. La única
ventaja de asignar nulos es que puedes tener una clave externa activa. O sea
la tabla podría tener una definición como esta:


CREATE TABLE Proyectos(
IdProyecto int PRIMARY KEY,
IdProyectoPadre int NULL REFERENCES Proyectos(IdProyecto),
NombreProyecto varchar(50) NOT NULL
)


Con la clave externa, SQL Server te asegura que los proyectos no se quedan
huérfanos, a la vez que permite proyectos de primer nivel (IdProyectoPadre
nulo). Pero esta clave externa tiene una seria limitación: no funcionan las
eliminaciones en cascada. Esto hace muy complicado eliminar un proyecto y
sus subproyectos ya que hay que empezar por el nivel hoja del árbol e ir
subiendo o quizá optar por borrado lógico. Al final puede que no merezca la
pena tener la clave externa activa y termines desactivándola, no la
eliminarías porque así al menos quedaría como documentación al salir en los
diagramas.

Por otra parte los nulos siempre son un fastidio, hay que andar con el IS
NULL y el IS NOT NULL. Por ejemplo un procedimiento almacenado que devuelve
los proyectos hijo de un determinado proyecto sería así:

CREATE PROCEDURE ProyectosHijo @IdProyectoPadre int
AS
SELECT * FROM Proyectos WHERE IdProyectoPadre = @IdProyectoPadre


Si usamos nulos para los proyectos de primer nivel, este procedimiento no
nos sirve para sacar los proyectos de primer nivel ya que si le pasamos NULL
como @IdProyectoPadre no nos devuelve ningún registro. Sin embargo si usamos
ceros para los proyectos de primer nivel, este procedimiento sirve.

Si usamos nulos para los proyectos de primer nivel, tendríamos que
reescribir el procedimiento así:

CREATE PROCEDURE ProyectosHijo @IdProyectoPadre int
AS
IF @IdProyectoPadre IS NULL
SELECT * FROM Proyectos WHERE IdProyectoPadre IS NULL
ELSE
SELECT * FROM Proyectos WHERE IdProyectoPadre = @IdProyectoPadre

Y además si es por documentación, también podemos añadir la clave externa
desactivada cuando usamos ceros:

CREATE TABLE Proyectos(
IdProyecto int PRIMARY KEY,
IdProyectoPadre int NOT NULL DEFAULT 0,
NombreProyecto varchar(50) NOT NULL
)

INSERT INTO Proyectos VALUES(1,0, 'Proyecto 1')



ALTER TABLE Proyectos WITH NOCHECK ADD CONSTRAINT FK_ArbolProyectos
FOREIGN KEY(IdProyectoPadre) REFERENCES Proyectos(IdProyecto)



ALTER TABLE Proyectos NOCHECK CONSTRAINT FK_ArbolProyectos

Después de haber leído todo este rollo, ¿sigues pensando que es un error
poner ceros en lugar de nulos?


Saludos:


Jesús López
www.solidq.com




"Mauricio" escribió en el mensaje
news:

Jesús,
cuando vi tu respuesta no pude dejar de reírme!!! No quise poner que era
esa la función que necesitaba para que no te sintieras obligado a
responderme (dado que ya me habías ayudado antes) pero lo adivinaste y
enviaste la respuesta exacta. Solo hice una modificación y es la condición
del WHILE, le puse WHILE @IdProyectoPadre <> 0 y me funcionó, en realidad
le estoy asignando 0 cuando no hay padre (tal vez un error mío, lo sé).
Nuevamente: MUCHAS GRACIAS!!!!
Saludos.

Mauricio
Copenhague, Dinamarca

Jesús López avait soumis l'idée :

Tal vez sea un error asignar 0 cuando no hay padre y tal vez no. La única
ventaja de asignar nulos es que puedes tener una clave externa activa. O sea
la tabla podría tener una definición como esta:


CREATE TABLE Proyectos(
IdProyecto int PRIMARY KEY,
IdProyectoPadre int NULL REFERENCES Proyectos(IdProyecto),
NombreProyecto varchar(50) NOT NULL
)


Con la clave externa, SQL Server te asegura que los proyectos no se quedan
huérfanos, a la vez que permite proyectos de primer nivel (IdProyectoPadre
nulo). Pero esta clave externa tiene una seria limitación: no funcionan las
eliminaciones en cascada. Esto hace muy complicado eliminar un proyecto y sus
subproyectos ya que hay que empezar por el nivel hoja del árbol e ir subiendo
o quizá optar por borrado lógico. Al final puede que no merezca la pena tener
la clave externa activa y termines desactivándola, no la eliminarías porque
así al menos quedaría como documentación al salir en los diagramas.

Por otra parte los nulos siempre son un fastidio, hay que andar con el IS
NULL y el IS NOT NULL. Por ejemplo un procedimiento almacenado que devuelve
los proyectos hijo de un determinado proyecto sería así:

CREATE PROCEDURE ProyectosHijo @IdProyectoPadre int
AS
SELECT * FROM Proyectos WHERE IdProyectoPadre = @IdProyectoPadre


Si usamos nulos para los proyectos de primer nivel, este procedimiento no nos
sirve para sacar los proyectos de primer nivel ya que si le pasamos NULL como
@IdProyectoPadre no nos devuelve ningún registro. Sin embargo si usamos ceros
para los proyectos de primer nivel, este procedimiento sirve.

Si usamos nulos para los proyectos de primer nivel, tendríamos que reescribir
el procedimiento así:

CREATE PROCEDURE ProyectosHijo @IdProyectoPadre int
AS
IF @IdProyectoPadre IS NULL
SELECT * FROM Proyectos WHERE IdProyectoPadre IS NULL
ELSE
SELECT * FROM Proyectos WHERE IdProyectoPadre = @IdProyectoPadre

Y además si es por documentación, también podemos añadir la clave externa
desactivada cuando usamos ceros:

CREATE TABLE Proyectos(
IdProyecto int PRIMARY KEY,
IdProyectoPadre int NOT NULL DEFAULT 0,
NombreProyecto varchar(50) NOT NULL
)

INSERT INTO Proyectos VALUES(1,0, 'Proyecto 1')



ALTER TABLE Proyectos WITH NOCHECK ADD CONSTRAINT FK_ArbolProyectos
FOREIGN KEY(IdProyectoPadre) REFERENCES Proyectos(IdProyecto)



ALTER TABLE Proyectos NOCHECK CONSTRAINT FK_ArbolProyectos

Después de haber leído todo este rollo, ¿sigues pensando que es un error
poner ceros en lugar de nulos?


Saludos:


Jesús López
www.solidq.com




"Mauricio" escribió en el mensaje
news:

Jesús,
cuando vi tu respuesta no pude dejar de reírme!!! No quise poner que era
esa la función que necesitaba para que no te sintieras obligado a
responderme (dado que ya me habías ayudado antes) pero lo adivinaste y
enviaste la respuesta exacta. Solo hice una modificación y es la condición
del WHILE, le puse WHILE @IdProyectoPadre <> 0 y me funcionó, en realidad
le estoy asignando 0 cuando no hay padre (tal vez un error mío, lo sé).
Nuevamente: MUCHAS GRACIAS!!!!
Saludos.

Copenhague, Dinamarca

No, ahora creo que no he estado tan errado. Además soy yo el que
controla el valor a asignar al campo. Podría hacer un Zero is null (una
sentencia del lenguaje que uso) y resolvería el problema, pero me
resulta más fácil tener el 0.
Nuevamente, muchas gracias por tu respuesta.
Un saludo.

Mauricio
Copenhague, Dinamarca