Forums Últimos mensajes - Powered by IBM
 
Tags Palabras claves

El nombre del objeto no es válido (UDF)

18/11/2008 - 10:58 por JuanD | Informe spam
Ayuda Hacer una pregunta
Hola,

He creado la siguiente función que en teoría debería devolver la fecha de
los días con sábados que hay desde una fecha hasta hoy (desde el QA
funciona);

CREATE FUNCTION dbo.Sabados (@FechaI smalldatetime)
RETURNS @Tabla TABLE (Fecha smalldatetime)
BEGIN
declare @i int
declare @dia varchar(20)
declare @fecha datetime
select @i = 0
while @i > - DateDiff(Day, '01/10/2008', @FechaI)
begin
select @dia = DateName(dw, dateadd(d, @i, @FechaI))
select @fecha = DateAdd(d, @i, @FechaI)
if @dia in ('Sábado')
begin
INSERT INTO @Tabla Select convert(nvarchar, @fecha, 103)
end
select @i = @i - 1
end
RETURN
END

A la hora de llamarla así; Select dbo.Sabados(getdate()), me lanza el
siguiente error;

Servidor: mensaje 208, nivel 16, estado 1, línea 1
El nombre de objeto 'dbo.Sabados' no es válido.

Cuando se que el nombre de la función existe y que funciona si ejecuto el
código desde el QA, ¿qué estoy haciendo mal?.
Utilizo SQL Server 2000 SP4.
Gracias.
email Siga el debateRespuesta 54 respuestasRespuesta Tengo una respuesta

Preguntas similare

Leer las respuestas

#31 Carlos M. Calvelo
18/11/2008 - 21:12 | Informe spam
On 18 nov, 20:32, "Jose TH" <>>> wrote:
Ya empieza.

>> Por nada aunque con ese ejemplo cuando cambies de año tendrás que
>> modificar
>> la definición de la vista. .
>Por que tu lo digas.

Pues no porque yo lo diga.

Cualquiera con un mínimo de sentido común y conocimiento que se tope con una
vista con CONSTANTES incrustadas como ésta:

create view vSabados as
select * from dbo.Fechas('20080101', '20101231') where diasemana=0

Y no le quedaría más que decir que quien la pensó no se le ocurrió que hay
vida después del 2010. Qué brillante diseño!.




Serás cateto! Ese es solo un ejemplo de como se puede usar la
función. La esencia es que los datos se presentan en forma
de tabla (vSabados) con las columnas que sea. La expresión
que define la vista es implementación. Nadie ha dicho que ponga
2010 en su solución final. Y hasta he propuesto usar una tabla
en vez de (o debajo de) la vista. Que no te enteras!

Tengo para ti un par de conceptos esenciales que se tienen que
tener en cuenta con el diseño lógico:
- Principio de Información
- Cierre relacional
- Independiencia lógica de datos
- Principio de intercambiabilidad




> >Yo evaluaría finalmente la necesidad de tener una vista así y no mejor
> >hacer
> >un Store procedure.
>Yo no.

Claro que no, es que tu mente anti Store Procedure no te permite admitir la
tontería que has planteado y que un store procedure puede usarse alguna vez.



Yo no soy anti nada, imbécil. Pero cada cosa para lo que es.
Y claro que se pueden usar alguna vez. Y a menudo también.



Nota: Cuando vuelvas a plagiar la idea de otro, como la de la suma de 7
días, por lo menos da los créditos sí? copión! :)



:o Vaya acusación! Cómo está el patio! :D

Que de sábado a sábado van siete días es una novedad! :)
Te refieres a eso?!!! Si quieres aceptamos eso como tu
aportación a la ciencia. Es una idea fundamental!

Vete a leer un libro, anda! Que total no creo que te enteres de
que estoy hablando. Idiota! O vete a hacer la contabilidad.
Respuesta Responder a este mensaje
#32 Jose TH
18/11/2008 - 22:26 | Informe spam

>> Por nada aunque con ese ejemplo cuando cambies de año tendrás que
>> modificar
>> la definición de la vista. .
>Por que tu lo digas.

Pues no porque yo lo diga.

Cualquiera con un mínimo de sentido común y conocimiento que se tope con
una
vista con CONSTANTES incrustadas como ésta:

create view vSabados as
select * from dbo.Fechas('20080101', '20101231') where diasemana=0

Y no le quedaría más que decir que quien la pensó no se le ocurrió que hay
vida después del 2010. Qué brillante diseño!.
Serás cateto!
Ese es solo un ejemplo de como se puede usar la
función.



Ahora es "un ejemplo" que pusiste. Si hasta pusiste "CREATE VIEW". Busca
tu propio mensaje y lo verás.

No te sientas mal, entiendo tu enfado y tus insultos. Cualquiera se puede
equivocar y decir de vez en cuando, o muchas veces :), una barrabasada como
esa, hombre, no eres infalible.

Por cierto, no sé qué es "cateto" pero gracias, "colega".:)

La esencia es que los datos se presentan en forma
de tabla (vSabados) con las columnas que sea. La expresión
que define la vista es implementación. Nadie ha dicho que ponga
2010 en su solución final.




Pues lee tu propio mensaje. Ahora quieres decir lo contrario. Miralo aquí
ya que quieres desmentir lo que escribiste:

"Ahora podemos utilizarla por ejemplo así:
select * from dbo.Fechas('20080101', '20101231')
o crear una vista: <=FIJATE QUE DICE "VISTA"

create view vSabados as <=FIJATE QUE DICE "CREATE VIEW"
select * from dbo.Fechas('20080101', '20101231') where diasemana=0
/* 0=Sábado, 1=Domingo, etc. */
"
O "CREATE VIEW" no es para definir una VISTA ?
Si no quisiste decir eso ahora pues estoy seguro de que confundiste
totalmente al OP y a todo el que lo leyó.

" La expresión que define la vista es implementación... Nadie ha dicho que
ponga
2010 en su solución final."



De cuál implementación hablas ? poner en vez de sólo hasta 2010 poner, por
ejemplo hasta el 2030 ? Es esa tu "implementación" ?

algo asi?:
create view vSabados as <=FIJATE QUE DICE "CREATE VIEW"
select * from dbo.Fechas('20080101', '20301231') where diasemana=0" ?

Supongamos que algo así es tu "implementación". Has pensado en el
performance de esa llamada a esa función para solo sacar los sábados de un
solo año o de un sólo mes ? parece que definitivamente no has pensado en
eso entonces de cuál implementación hablas!
Peor de ahí no puede ser. O quien sabe qué es lo que tu entiendes por
"implementación", estar modificando las vistas anualmente ?


Y hasta he propuesto usar una tabla
en vez de (o debajo de) la vista. Que no te enteras!



Pues claro que eso es OTRA cosa. Y esa debió ser quizá tu "mejor" solución,
porque... tabla y vista no es lo mismo, sabías? Tampoco hablaste de "Vista
materializada". Sabías ? :)
Pero para eso no tenías que quemarte las neuronas haciendo una función y
luego salir con el genial "CREATE VIEW" basado en la función con parámetros
constantes cuyo rango de años va a definirse en la "implementación".
Todo por no pensar en un store procedure al cual se le puede pasar como
parámetro getdate() en cualquier versión de SS o en su defecto usar la tabla
persistente como también propuso Alejandro. Que quizas el SP no se puede
llamar en un FROM?, para eso están las tablas temporales, eso es por lo
menos mas simple, mas eficiente o mas mantenible que la solucion que das.
Pero nada, me quedo con lo de la tabla calendario que propone Alejandro.

Tengo para ti un par de conceptos esenciales que se tienen que
ener en cuenta con el diseño lógico:
Principio de Información
Cierre relacional
Independiencia lógica de datos
Principio de intercambiabilidad



te felicito, se nota que estás leyendo. Seguro que allí nunca verás la
recomendación de hacer un CREATE VIEW con fechas constantes. O sí? a lo
mejor quien sabe :)
Por cierto, lo buscaste en la WikiPedia ???


> >Yo evaluaría finalmente la necesidad de tener una vista así y no mejor
> >hacer
> >un Store procedure.
>Yo no.

Claro que no, es que tu mente anti Store Procedure no te permite admitir
la
tontería que has planteado y que un store procedure puede usarse alguna
vez.


Yo no soy anti nada, imbécil.




Pues ahora dices que no lo eres porque no te conviene decirlo pero crees que
no estamos hartos de leer todos tus mensajes al respecto y los de tu
apreciado compañerito Novoa, donde insultan a todo el que defiende un
poquito a los store procedures ?

Pero cada cosa para lo que es.
Y claro que se pueden usar alguna vez. Y a menudo también.



Eso!!! por fin!... te felicito. :)


Nota: Cuando vuelvas a plagiar la idea de otro, como la de la suma de 7
días, por lo menos da los créditos sí? copión! :)
:o Vaya acusación! Cómo está el patio! :D
Que de sábado a sábado van siete días es una novedad! :)
?Te refieres a eso?!!! Si quieres aceptamos eso como tu
aportación a la ciencia. Es una idea fundamental!




Pues claro porque hiciste la función originalmente sin eso, yendo día por
día, luego la corregiste después de leer mi mensaje pero, sabes algo? que
todavía se puede simplificar más. Anda! te lo dejo como tarea no te
preocupes, te perdono el plagio. :)

Vete a leer un libro, anda! Que total no creo que te enteres de
que estoy hablando. Idiota! O vete a hacer la contabilidad.



De nuevo, tus insultos te delatan. Para los demás lectores del foro que
vean de qué es que se tratan tus brillantes argumentos.

Dime en qué página del libro de tu ídolo CJ Date se recomienda que se
defina una vista como esta:

"create view vSabados as
select * from dbo.Fechas('20080101', '20101231') where diasemana=0"
y peor aún basada en una función como la propuesta?

O es en la Wikipedia que lo dice?

Hombre, hablando con seriedad, a quién se le ocurre ? y menos recomendarlo
en un foro como este con tanta gente experta.

No tienes por qué ponerte así y andar insultando porque alguien haya
observado ese mal intento que has dado como solución, por no decir otra
cosa.

Yo te exhorto humildemente que no tomes un foro para recomendar cosas como
esa, ya que la gente que está aprendiendo puede confundirse como le ha
pasado sin duda ninguna al OP.

Todavía estás a tiempo. Y, por cierto, contabilidad es mi otra profesión, a
mucho orgullo, y no me siento denigrado en lo absoluto por tu acostumbrada,
discriminadora y maliciosa insinuación.

Vete a tomar un té que le hará bien a ese mal genio. :)
Respuesta Responder a este mensaje
#33 Carlos M. Calvelo
18/11/2008 - 23:18 | Informe spam
Hola Imbécil,

On 18 nov, 22:26, "Jose TH" <>>> wrote:
> >> Por nada aunque con ese ejemplo cuando cambies de año tendrás que
> >> modificar
> >> la definición de la vista. .
> >Por que tu lo digas.

> Pues no porque yo lo diga.

> Cualquiera con un mínimo de sentido común y conocimiento que se tope con
> una
> vista con CONSTANTES incrustadas como ésta:

> create view vSabados as
> select * from dbo.Fechas('20080101', '20101231') where diasemana=0

> Y no le quedaría más que decir que quien la pensó no se le ocurrió que hay
> vida después del 2010. Qué brillante diseño!.
>Serás cateto!
>Ese es solo un ejemplo de como se puede usar la
>función.

Ahora es "un ejemplo" que pusiste. Si hasta pusiste "CREATE VIEW". Busca
tu propio mensaje y lo verás.



De mi reacción original:

- Ahora podemos utilizarla por ejemplo así:
-
- select * from dbo.Fechas('20080101', '20101231')
-
- o crear una vista:
-
-

Pone claramente 'podemos *por ejemplo* ...'


No te sientas mal, entiendo tu enfado y tus insultos.



Nunca me he encontrado mejor y no estoy enfadado.
Y que entiendas los insultos... lo dudo.


Cualquiera se puede
equivocar y decir de vez en cuando, o muchas veces :), una barrabasada como
esa, hombre, no eres infalible.

Por cierto, no sé qué es "cateto" pero gracias, "colega".:)



Está en el diccinario con varios significados.
Me refiero al que no va de geometría.



>La esencia es que los datos se presentan en forma
>de tabla (vSabados) con las columnas que sea. La expresión
>que define la vista es implementación. Nadie ha dicho que ponga
>2010 en su solución final.

Pues lee tu propio mensaje. Ahora quieres decir lo contrario. Miralo aquí
ya que quieres desmentir lo que escribiste:

"Ahora podemos utilizarla por ejemplo así:
select * from dbo.Fechas('20080101', '20101231')
o crear una vista: <=FIJATE QUE DICE "VISTA"

create view vSabados as <=FIJATE QUE DICE "CREATE VIEW"
select * from dbo.Fechas('20080101', '20101231') where diasemana=0
/* 0=Sábado, 1=Domingo, etc. */
"
O "CREATE VIEW" no es para definir una VISTA ?
Si no quisiste decir eso ahora pues estoy seguro de que confundiste
totalmente al OP y a todo el que lo leyó.



Si y todos son ejemplos. Por eso empieza todo con:
"Ahora podemos utilizarla por ejemplo así:"


>" La expresión que define la vista es implementación... Nadie ha dicho que
>ponga
>2010 en su solución final."

De cuál implementación hablas ?



Por eso tienes que ir a leer un libro.


poner en vez de sólo hasta 2010 poner, por
ejemplo hasta el 2030 ? Es esa tu "implementación" ?

algo asi?:
create view vSabados as <=FIJATE QUE DICE "CREATE VIEW"
select * from dbo.Fechas('20080101', '20301231') where diasemana=0" ?

Supongamos que algo así es tu "implementación". Has pensado en el
performance de esa llamada a esa función para solo sacar los sábados de un
solo año o de un sólo mes ? parece que definitivamente no has pensado en
eso entonces de cuál implementación hablas!




Si he pensando en eso. Y por eso también digo que la función
es genérica para poder ser ulizada en muchos contextos.
Y por eso propongo también utilizarla para generar una
tabla y utilizar la tabla. Imbécil, que no sabes ni leer.


Peor de ahí no puede ser. O quien sabe qué es lo que tu entiendes por
"implementación", estar modificando las vistas anualmente ?




Por eso tienes que ir a leer un libro.



> Y hasta he propuesto usar una tabla
>en vez de (o debajo de) la vista. Que no te enteras!

Pues claro que eso es OTRA cosa. Y esa debió ser quizá tu "mejor" solución,
porque... tabla y vista no es lo mismo, sabías? Tampoco hablaste de "Vista
materializada". Sabías ? :)



Si. Sabía! Por eso propongo usar la función para generar la tabla.

Y tabla y vista a nivel lógico si son lo mismo, borrico. Solo
la implementación es diferente. Vete a leer anda!

Es uno de los principios de los que te he hablado, pero
no te enteras.


Pero para eso no tenías que quemarte las neuronas haciendo una función y
luego salir con el genial "CREATE VIEW" basado en la función con parámetros
constantes cuyo rango de años va a definirse en la "implementación".



Lo de "implementación" te tiene ocupado eh!?
Ya sabes cual es la solución.


Todo por no pensar en un store procedure al cual se le puede pasar como
parámetro getdate() en cualquier versión de SS



Eso también lo puede hacer en una vista en SS2000. Borrico!


o en su defecto usar la tabla
persistente como también propuso Alejandro.



Lo que propone Alejandro tiene muchísimo mas sentido que lo
que propones tu. Eso es seguro.

Yo he dado la opción de utilizar la función para generar una
tabla. Lee!


Que quizas el SP no se puede
llamar en un FROM?, para eso están las tablas temporales, eso es por lo
menos mas simple, mas eficiente o mas mantenible que la solucion que das.
Pero nada, me quedo con lo de la tabla calendario que propone Alejandro.




Busca la palabra Calendario en mi primer reacción.
Se te ve el plumero!


>Tengo para ti un par de conceptos esenciales que se tienen que
>ener en cuenta con el diseño lógico:
> Principio de Información
> Cierre relacional
> Independiencia lógica de datos
> Principio de intercambiabilidad

te felicito, se nota que estás leyendo. Seguro que allí nunca verás la
recomendación de hacer un CREATE VIEW con fechas constantes. O sí? a lo
mejor quien sabe :)
Por cierto, lo buscaste en la WikiPedia ???



> > >Yo evaluaría finalmente la necesidad de tener una vista así y no mejor
> > >hacer
> > >un Store procedure.
> >Yo no.

> Claro que no, es que tu mente anti Store Procedure no te permite admitir
> la
> tontería que has planteado y que un store procedure puede usarse alguna
> vez.

>Yo no soy anti nada, imbécil.

Pues ahora dices que no lo eres porque no te conviene decirlo pero crees que
no estamos hartos de leer todos tus mensajes al respecto y los de tu
apreciado compañerito Novoa, donde insultan a todo el que defiende un
poquito a los store procedures ?



Pues no te has enterado. Criticamos 'cierto' uso de los SP.



>Pero cada cosa para lo que es.
>Y claro que se pueden usar alguna vez. Y a menudo también.

Eso!!! por fin!... te felicito. :)




Te felicito yo a tí por haberte enterado ahora de lo que ya sabe
todo el mundo desde hace tiempo.




> Nota: Cuando vuelvas a plagiar la idea de otro, como la de la suma de 7
> días, por lo menos da los créditos sí? copión! :)
>:o Vaya acusación! Cómo está el patio! :D
>Que de sábado a sábado van siete días es una novedad! :)
>?Te refieres a eso?!!! Si quieres aceptamos eso como tu
>aportación a la ciencia. Es una idea fundamental!

Pues claro porque hiciste la función originalmente sin eso, yendo día por
día, luego la corregiste después de leer mi mensaje pero, sabes algo? que
todavía se puede simplificar más. Anda! te lo dejo como tarea no te
preocupes, te perdono el plagio. :)



Pero que imbécil eres chico! Ya dije en el primer post que
era una función genérica, etc etc.

Tarea tienes tu ya bastante. Hala... a leer eh!



>Vete a leer un libro, anda! Que total no creo que te enteres de
>que estoy hablando. Idiota! O vete a hacer la contabilidad.

De nuevo, tus insultos te delatan. Para los demás lectores del foro que
vean de qué es que se tratan tus brillantes argumentos.



Mira quien habla! Eres un desvergonzado después de haberte
comportado tu como te has comportado.

Que tu no entiendas mis 'brillantes argumentos' no los
hace menos 'brillantes' :)



Dime en qué página del libro de tu ídolo CJ Date se recomienda que se
defina una vista como esta:



y por que no vas y lo lees tu?




"create view vSabados as
select * from dbo.Fechas('20080101', '20101231') where diasemana=0"
y peor aún basada en una función como la propuesta?

O es en la Wikipedia que lo dice?

Hombre, hablando con seriedad, a quién se le ocurre ? y menos recomendarlo
en un foro como este con tanta gente experta.



LOL Ahora hasta me estás pareciendo gracioso. :)

Vete tu a recomendar sp's para todo, anda!



No tienes por qué ponerte así y andar insultando porque alguien haya
observado ese mal intento que has dado como solución, por no decir otra
cosa.

Yo te exhorto humildemente que no tomes un foro para recomendar cosas como
esa, ya que la gente que está aprendiendo puede confundirse como le ha
pasado sin duda ninguna al OP.



'humildemente' dice! No sabes lo que significa la palabra.



Todavía estás a tiempo. Y, por cierto, contabilidad es mi otra profesión, a
mucho orgullo, y no me siento denigrado en lo absoluto por tu acostumbrada,
discriminadora y maliciosa insinuación.



Pero si no es denigración. Solo que pensé que tendrás que saber
hacer algo bien y quizás sea eso.


Vete a tomar un té que le hará bien a ese mal genio. :)



Acabo ya de tomar ya un par, gracias! Aunque estaba de
muy buen genio.
Pero no dá resultado; sigo pensando que eres un gran imbécil.

Espero que entiendas que esta conversación no va a dar mucho
mas de sí. O necesitas que alguien te explique eso también?
Respuesta Responder a este mensaje
#34 Jose TH
18/11/2008 - 23:22 | Informe spam
GETDATE() es una función 'nondeterministic' y no se puede
usar para definir UDF's (de las que se supone que si tienen
que ser 'deterministic').
Una función 'nondeterministic', realmente no es una función :)
Busca en la ayuda.




Para los demás que leen el foro y quieran estar mejor enterados sepan que en
las versiones 2008 (y creo que en 2005 también) ya eso no es así para
GETDATE, por lo menos.

Búsquenlo en la ayuda.
Respuesta Responder a este mensaje
#35 Carlos M. Calvelo
18/11/2008 - 23:37 | Informe spam
On 18 nov, 23:22, "Jose TH" <>>> wrote:
>GETDATE() es una función 'nondeterministic' y no se puede
>usar para definir UDF's (de las que se supone que si tienen
>que ser 'deterministic').
>Una función 'nondeterministic', realmente no es una función  :)
>Busca en la ayuda.

Para los demás que leen el foro y quieran estar mejor enterados sepan que en
las versiones 2008 (y creo que en 2005 también) ya eso no es así para
GETDATE, por lo menos.




Y GETDATE seguirá siendo una función 'nondetermistic', lo
cual no es *realmente* una función.
Pero eso no está en la ayuda. Borrico!
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida