Columna Calculada con indice

Tambien lo he intentado con una vista, y si no la indexo, funciona, al igual
que la columna calculada, si no es persistente. Por eso quiero hacer la
columna persistente, para que no la recalcule cada vez que la pido.

Cuando intento crear un indice sobre la vista para indexarla me da el mismo
error. Dice que no se puede porque la funcion tiene acceso a datos del
usuario o sistema.

Por eso pregunto si alguien ha hecho alguna vez algo parecido.

Tambien pregunto si ese error que me esta dando sobre --acceso a datos de
usuario o sistema-- se refiere a que la funcion esta accediendo a tablas
distintas a aquella sobre la que se crea la columna calculada.

De que otra manera puedo hacer esto mismo??? Con un triger insert sobre la
tabla calculos???



"Pedro Echavarria" escribió en el mensaje
news:Omut7%

GenioMaestro, porque mejor no haces una vista ? Yo creo que es mejor usar
una funcion en una columna calculada cuando sea una simple que no maneje
datos ya que el overhead puede ser muy alto.



"GenioMaestro" wrote in message
news:

Además he visto en el enlace que me pasaste que para que una funcion se
determinista dice literalmente:

Has no system data access or user data access. (No tiene acceso a los
datos del sistema o de usuario.)

Es decir, si accede a datos de usuario ya no es determinista, aunque la
primera de las tres select diga que si.

Es un poco absurdo, no???


"GenioMaestro" escribió en el mensaje
news:

Estas tres consultas me dan 1, lo que es lo mismo true, osea que la
funcion es determinista y precisa y se ha creado con la opcion SET
ANSI_NULLS ON activada.

SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'),
'IsDeterministic')
SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'), 'IsPrecise')
SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'), 'IsAnsiNullsOn')

Estoy mirando otra cosa. Y es que en los BOL, sobre las columnas
calculadas dice literalmente:

"Las columnas calculadas se calculan a partir de una expresión que puede
utilizar otras columnas de la misma tabla."

Dice de la misma tabla. Yo estoy intentando crear una columna calculada
con una funcion que tiene una select de otras dos tablas. Puede ser por
eso????

¿¿¿¿Alguien ha hecho alguna funcion de columna calculada persistente que
acceda a datos de otra tabla????

"Alejandro Mesa" escribió en
el mensaje news:

GenioMaestro,

Chequea el tema "Creating Indexes on Computed Columns" en los BOL.
Puede ser
que como calculas el valor a partir de multiples filas, esto hace que
la
funcion sea no determinista. Usa la funcion "objectproperty" para
comprobar
si la funcion es determinista y en caso de ser determinista verifica si
es
imprescisa, creo que en ese caso puedes usar la opcion "persisted"
cuando
creas la columna y sql server dejara crear un indice.

Creating Indexes on Computed Columns
http://msdn2.microsoft.com/en-us/li...89292.aspx

> SELECT TOP 1 COTIZACIONES.FECHA
> FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
> ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND
> COTIZACIONES.FECHA >>>>> > CALCULOS.FECHA_CAL
> WHERE COTIZACIONES.COD_VALOR = @entra_valor AND .CALCULOS.FECHA_CAL
> IS
> NULL
> ORDER BY COTIZACIONES.FECHA ASC

A proposito, yo no usaria "left join" para comprobar existencia. Usaria
el
operador "exists" a cambio. De todas maneras prueba ambas versiones a
ver
cual te da mejor resultado. Tambien ve si tener un indice en
[COTIZACIONES]
por [COD_VALOR] ayuda a mejorar el plan de ejecucion.

SELECT TOP 1
c.FECHA
FROM
DBO.COTIZACIONES as a
WHERE
c.COD_VALOR = @entra_valor
and not exists (
select *
from DBO.CALCULOS as b
where
b.COD_VALOR = a.COD_VALOR
and b.FECHA_CAL = a.FECHA
)
ORDER BY
c.FECHA ASC
go


AMB

"GenioMaestro" wrote:

Y además, esta consulta tampoco me la paraleliza, tarda dos o tres
minutos
en darme la select con la columna calculada, porque la está calculando
al
vuelo, cada vez que la pido, y con el micro al 50%, claro.

Hay alguna manera de forzar al sql server 2005 para que paralelize una
consulta????



"GenioMaestro" escribió en el mensaje
news:
> Va la funcion:
>
> ALTER FUNCTION [dbo].[FECHA_CAL_INI] (@entra_valor as INT)
> RETURNS DATETIME
> WITH SCHEMABINDING
> BEGIN
>
> RETURN (
> SELECT TOP 1 COTIZACIONES.FECHA
> FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
> ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND
> COTIZACIONES.FECHA >>>>> > CALCULOS.FECHA_CAL
> WHERE COTIZACIONES.COD_VALOR = @entra_valor AND .CALCULOS.FECHA_CAL
> IS
> NULL
> ORDER BY COTIZACIONES.FECHA ASC
> )
> END
>
> Gracias por el interes, Alejandro.
>
>
>
> "Alejandro Mesa" escribió
> en el
> mensaje news:
>> GenioMaestro,
>>
>> Pudieras mostrarnos la funcion?
>>
>>
>> AMB
>>
>> "GenioMaestro" wrote:
>>
>>> Hola:
>>>
>>> He creado una columna calculada en base a una funcion de usuario
>>> que
>>> funciona bien, pero es muy lenta.
>>>
>>> Cuando intento crear un indice sobre esa columna sql 2005 me dice:
>>>
>>> Mens. 2709, Nivel 16, Estado 1, Línea 1
>>> La columna 'F_CAL_INI' de tabla 'VALORES' no se puede usar en un
>>> índice
>>> o en
>>> estadísticas, o como una clave de partición, porque tiene acceso a
>>> datos
>>> del
>>> usuario o sistema.
>>>
>>> Alguien puede decirme a que es debido y como solucionarlo???
>>>
>>> Gracias
>>>
>>>
>>>
>
>

Yo creo que puedes tratar el viejo artificio de los campos calculados en
triggers. Actualiza tu campo cada vez que se modifiquen los campos
correspondientes de la tabla origen.


"GenioMaestro" escribió en el mensaje
news:

Tambien lo he intentado con una vista, y si no la indexo, funciona, al
igual que la columna calculada, si no es persistente. Por eso quiero hacer
la columna persistente, para que no la recalcule cada vez que la pido.

Cuando intento crear un indice sobre la vista para indexarla me da el
mismo error. Dice que no se puede porque la funcion tiene acceso a datos
del usuario o sistema.

Por eso pregunto si alguien ha hecho alguna vez algo parecido.

Tambien pregunto si ese error que me esta dando sobre --acceso a datos de
usuario o sistema-- se refiere a que la funcion esta accediendo a tablas
distintas a aquella sobre la que se crea la columna calculada.

De que otra manera puedo hacer esto mismo??? Con un triger insert sobre la
tabla calculos???



"Pedro Echavarria" escribió en el mensaje
news:Omut7%

GenioMaestro, porque mejor no haces una vista ? Yo creo que es mejor
usar una funcion en una columna calculada cuando sea una simple que no
maneje datos ya que el overhead puede ser muy alto.



"GenioMaestro" wrote in message
news:

Además he visto en el enlace que me pasaste que para que una funcion se
determinista dice literalmente:

Has no system data access or user data access. (No tiene acceso a los
datos del sistema o de usuario.)

Es decir, si accede a datos de usuario ya no es determinista, aunque la
primera de las tres select diga que si.

Es un poco absurdo, no???


"GenioMaestro" escribió en el mensaje
news:

Estas tres consultas me dan 1, lo que es lo mismo true, osea que la
funcion es determinista y precisa y se ha creado con la opcion SET
ANSI_NULLS ON activada.

SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'),
'IsDeterministic')
SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'), 'IsPrecise')
SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'),
'IsAnsiNullsOn')

Estoy mirando otra cosa. Y es que en los BOL, sobre las columnas
calculadas dice literalmente:

"Las columnas calculadas se calculan a partir de una expresión que
puede utilizar otras columnas de la misma tabla."

Dice de la misma tabla. Yo estoy intentando crear una columna calculada
con una funcion que tiene una select de otras dos tablas. Puede ser por
eso????

¿¿¿¿Alguien ha hecho alguna funcion de columna calculada persistente
que acceda a datos de otra tabla????

"Alejandro Mesa" escribió en
el mensaje news:

GenioMaestro,

Chequea el tema "Creating Indexes on Computed Columns" en los BOL.
Puede ser
que como calculas el valor a partir de multiples filas, esto hace que
la
funcion sea no determinista. Usa la funcion "objectproperty" para
comprobar
si la funcion es determinista y en caso de ser determinista verifica
si es
imprescisa, creo que en ese caso puedes usar la opcion "persisted"
cuando
creas la columna y sql server dejara crear un indice.

Creating Indexes on Computed Columns
http://msdn2.microsoft.com/en-us/li...89292.aspx

> SELECT TOP 1 COTIZACIONES.FECHA
> FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
> ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND
> COTIZACIONES.FECHA >>>>>> > CALCULOS.FECHA_CAL
> WHERE COTIZACIONES.COD_VALOR = @entra_valor AND .CALCULOS.FECHA_CAL
> IS
> NULL
> ORDER BY COTIZACIONES.FECHA ASC

A proposito, yo no usaria "left join" para comprobar existencia.
Usaria el
operador "exists" a cambio. De todas maneras prueba ambas versiones a
ver
cual te da mejor resultado. Tambien ve si tener un indice en
[COTIZACIONES]
por [COD_VALOR] ayuda a mejorar el plan de ejecucion.

SELECT TOP 1
c.FECHA
FROM
DBO.COTIZACIONES as a
WHERE
c.COD_VALOR = @entra_valor
and not exists (
select *
from DBO.CALCULOS as b
where
b.COD_VALOR = a.COD_VALOR
and b.FECHA_CAL = a.FECHA
)
ORDER BY
c.FECHA ASC
go


AMB

"GenioMaestro" wrote:

Y además, esta consulta tampoco me la paraleliza, tarda dos o tres
minutos
en darme la select con la columna calculada, porque la está
calculando al
vuelo, cada vez que la pido, y con el micro al 50%, claro.

Hay alguna manera de forzar al sql server 2005 para que paralelize
una
consulta????



"GenioMaestro" escribió en el mensaje
news:
> Va la funcion:
>
> ALTER FUNCTION [dbo].[FECHA_CAL_INI] (@entra_valor as INT)
> RETURNS DATETIME
> WITH SCHEMABINDING
> BEGIN
>
> RETURN (
> SELECT TOP 1 COTIZACIONES.FECHA
> FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
> ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND
> COTIZACIONES.FECHA >>>>>> > CALCULOS.FECHA_CAL
> WHERE COTIZACIONES.COD_VALOR = @entra_valor AND .CALCULOS.FECHA_CAL
> IS
> NULL
> ORDER BY COTIZACIONES.FECHA ASC
> )
> END
>
> Gracias por el interes, Alejandro.
>
>
>
> "Alejandro Mesa" escribió
> en el
> mensaje news:
>> GenioMaestro,
>>
>> Pudieras mostrarnos la funcion?
>>
>>
>> AMB
>>
>> "GenioMaestro" wrote:
>>
>>> Hola:
>>>
>>> He creado una columna calculada en base a una funcion de usuario
>>> que
>>> funciona bien, pero es muy lenta.
>>>
>>> Cuando intento crear un indice sobre esa columna sql 2005 me
>>> dice:
>>>
>>> Mens. 2709, Nivel 16, Estado 1, Línea 1
>>> La columna 'F_CAL_INI' de tabla 'VALORES' no se puede usar en un
>>> índice
>>> o en
>>> estadísticas, o como una clave de partición, porque tiene acceso
>>> a datos
>>> del
>>> usuario o sistema.
>>>
>>> Alguien puede decirme a que es debido y como solucionarlo???
>>>
>>> Gracias
>>>
>>>
>>>
>
>

Fuera la columna calculada.

El objetivo de la funcion es dar la primera fecha de cotizacion que NO
exista en la tabla de calculos.

He puesto dos trigers, uno en cotizaciones y otro en calculos, de forma que
cuando se insertan o borran registros en cualquiera de las dos tablas se
ejecuta la funcion y escribe el resultado en valores, donde queria poner la
columna calculada.

Tal y como dice Ricardo, mantengo el valor de la columna mediante trigers.

Listo.

"Ricardo Passians" escribió en el mensaje
news:

Yo creo que puedes tratar el viejo artificio de los campos calculados en
triggers. Actualiza tu campo cada vez que se modifiquen los campos
correspondientes de la tabla origen.


"GenioMaestro" escribió en el mensaje
news:

Tambien lo he intentado con una vista, y si no la indexo, funciona, al
igual que la columna calculada, si no es persistente. Por eso quiero
hacer la columna persistente, para que no la recalcule cada vez que la
pido.

Cuando intento crear un indice sobre la vista para indexarla me da el
mismo error. Dice que no se puede porque la funcion tiene acceso a datos
del usuario o sistema.

Por eso pregunto si alguien ha hecho alguna vez algo parecido.

Tambien pregunto si ese error que me esta dando sobre --acceso a datos de
usuario o sistema-- se refiere a que la funcion esta accediendo a tablas
distintas a aquella sobre la que se crea la columna calculada.

De que otra manera puedo hacer esto mismo??? Con un triger insert sobre
la tabla calculos???



"Pedro Echavarria" escribió en el mensaje
news:Omut7%

GenioMaestro, porque mejor no haces una vista ? Yo creo que es mejor
usar una funcion en una columna calculada cuando sea una simple que no
maneje datos ya que el overhead puede ser muy alto.



"GenioMaestro" wrote in message
news:

Además he visto en el enlace que me pasaste que para que una funcion
se determinista dice literalmente:

Has no system data access or user data access. (No tiene acceso a los
datos del sistema o de usuario.)

Es decir, si accede a datos de usuario ya no es determinista, aunque la
primera de las tres select diga que si.

Es un poco absurdo, no???


"GenioMaestro" escribió en el mensaje
news:

Estas tres consultas me dan 1, lo que es lo mismo true, osea que la
funcion es determinista y precisa y se ha creado con la opcion SET
ANSI_NULLS ON activada.

SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'),
'IsDeterministic')
SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'), 'IsPrecise')
SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'),
'IsAnsiNullsOn')

Estoy mirando otra cosa. Y es que en los BOL, sobre las columnas
calculadas dice literalmente:

"Las columnas calculadas se calculan a partir de una expresión que
puede utilizar otras columnas de la misma tabla."

Dice de la misma tabla. Yo estoy intentando crear una columna
calculada con una funcion que tiene una select de otras dos tablas.
Puede ser por eso????

¿¿¿¿Alguien ha hecho alguna funcion de columna calculada persistente
que acceda a datos de otra tabla????

"Alejandro Mesa" escribió en
el mensaje news:

GenioMaestro,

Chequea el tema "Creating Indexes on Computed Columns" en los BOL.
Puede ser
que como calculas el valor a partir de multiples filas, esto hace que
la
funcion sea no determinista. Usa la funcion "objectproperty" para
comprobar
si la funcion es determinista y en caso de ser determinista verifica
si es
imprescisa, creo que en ese caso puedes usar la opcion "persisted"
cuando
creas la columna y sql server dejara crear un indice.

Creating Indexes on Computed Columns
http://msdn2.microsoft.com/en-us/li...89292.aspx

> SELECT TOP 1 COTIZACIONES.FECHA
> FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
> ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND
> COTIZACIONES.FECHA >>>>>>> > CALCULOS.FECHA_CAL
> WHERE COTIZACIONES.COD_VALOR = @entra_valor AND
> .CALCULOS.FECHA_CAL IS
> NULL
> ORDER BY COTIZACIONES.FECHA ASC

A proposito, yo no usaria "left join" para comprobar existencia.
Usaria el
operador "exists" a cambio. De todas maneras prueba ambas versiones a
ver
cual te da mejor resultado. Tambien ve si tener un indice en
[COTIZACIONES]
por [COD_VALOR] ayuda a mejorar el plan de ejecucion.

SELECT TOP 1
c.FECHA
FROM
DBO.COTIZACIONES as a
WHERE
c.COD_VALOR = @entra_valor
and not exists (
select *
from DBO.CALCULOS as b
where
b.COD_VALOR = a.COD_VALOR
and b.FECHA_CAL = a.FECHA
)
ORDER BY
c.FECHA ASC
go


AMB

"GenioMaestro" wrote:

Y además, esta consulta tampoco me la paraleliza, tarda dos o tres
minutos
en darme la select con la columna calculada, porque la está
calculando al
vuelo, cada vez que la pido, y con el micro al 50%, claro.

Hay alguna manera de forzar al sql server 2005 para que paralelize
una
consulta????



"GenioMaestro" escribió en el mensaje
news:
> Va la funcion:
>
> ALTER FUNCTION [dbo].[FECHA_CAL_INI] (@entra_valor as INT)
> RETURNS DATETIME
> WITH SCHEMABINDING
> BEGIN
>
> RETURN (
> SELECT TOP 1 COTIZACIONES.FECHA
> FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
> ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND
> COTIZACIONES.FECHA >>>>>>> > CALCULOS.FECHA_CAL
> WHERE COTIZACIONES.COD_VALOR = @entra_valor AND
> .CALCULOS.FECHA_CAL IS
> NULL
> ORDER BY COTIZACIONES.FECHA ASC
> )
> END
>
> Gracias por el interes, Alejandro.
>
>
>
> "Alejandro Mesa"
> escribió en el
> mensaje news:
>> GenioMaestro,
>>
>> Pudieras mostrarnos la funcion?
>>
>>
>> AMB
>>
>> "GenioMaestro" wrote:
>>
>>> Hola:
>>>
>>> He creado una columna calculada en base a una funcion de usuario
>>> que
>>> funciona bien, pero es muy lenta.
>>>
>>> Cuando intento crear un indice sobre esa columna sql 2005 me
>>> dice:
>>>
>>> Mens. 2709, Nivel 16, Estado 1, Línea 1
>>> La columna 'F_CAL_INI' de tabla 'VALORES' no se puede usar en un
>>> índice
>>> o en
>>> estadísticas, o como una clave de partición, porque tiene acceso
>>> a datos
>>> del
>>> usuario o sistema.
>>>
>>> Alguien puede decirme a que es debido y como solucionarlo???
>>>
>>> Gracias
>>>
>>>
>>>
>
>

Gracias por compartir la solucion.
Yo tambien he usado cosas asi, no es que sea la unica solucion pero a veces
es la mas rapida.


"GenioMaestro" escribió en el mensaje
news:%

Fuera la columna calculada.

El objetivo de la funcion es dar la primera fecha de cotizacion que NO
exista en la tabla de calculos.

He puesto dos trigers, uno en cotizaciones y otro en calculos, de forma
que cuando se insertan o borran registros en cualquiera de las dos tablas
se ejecuta la funcion y escribe el resultado en valores, donde queria
poner la columna calculada.

Tal y como dice Ricardo, mantengo el valor de la columna mediante trigers.

Listo.

"Ricardo Passians" escribió en el mensaje
news:

Yo creo que puedes tratar el viejo artificio de los campos calculados en
triggers. Actualiza tu campo cada vez que se modifiquen los campos
correspondientes de la tabla origen.


"GenioMaestro" escribió en el mensaje
news:

Tambien lo he intentado con una vista, y si no la indexo, funciona, al
igual que la columna calculada, si no es persistente. Por eso quiero
hacer la columna persistente, para que no la recalcule cada vez que la
pido.

Cuando intento crear un indice sobre la vista para indexarla me da el
mismo error. Dice que no se puede porque la funcion tiene acceso a datos
del usuario o sistema.

Por eso pregunto si alguien ha hecho alguna vez algo parecido.

Tambien pregunto si ese error que me esta dando sobre --acceso a datos
de usuario o sistema-- se refiere a que la funcion esta accediendo a
tablas distintas a aquella sobre la que se crea la columna calculada.

De que otra manera puedo hacer esto mismo??? Con un triger insert sobre
la tabla calculos???



"Pedro Echavarria" escribió en el mensaje
news:Omut7%

GenioMaestro, porque mejor no haces una vista ? Yo creo que es mejor
usar una funcion en una columna calculada cuando sea una simple que no
maneje datos ya que el overhead puede ser muy alto.



"GenioMaestro" wrote in message
news:

Además he visto en el enlace que me pasaste que para que una funcion
se determinista dice literalmente:

Has no system data access or user data access. (No tiene acceso a los
datos del sistema o de usuario.)

Es decir, si accede a datos de usuario ya no es determinista, aunque
la primera de las tres select diga que si.

Es un poco absurdo, no???


"GenioMaestro" escribió en el mensaje
news:

Estas tres consultas me dan 1, lo que es lo mismo true, osea que la
funcion es determinista y precisa y se ha creado con la opcion SET
ANSI_NULLS ON activada.

SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'),
'IsDeterministic')
SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'), 'IsPrecise')
SELECT OBJECTPROPERTY ( OBJECT_ID('DBO.FECHA_CAL_INI'),
'IsAnsiNullsOn')

Estoy mirando otra cosa. Y es que en los BOL, sobre las columnas
calculadas dice literalmente:

"Las columnas calculadas se calculan a partir de una expresión que
puede utilizar otras columnas de la misma tabla."

Dice de la misma tabla. Yo estoy intentando crear una columna
calculada con una funcion que tiene una select de otras dos tablas.
Puede ser por eso????

¿¿¿¿Alguien ha hecho alguna funcion de columna calculada persistente
que acceda a datos de otra tabla????

"Alejandro Mesa" escribió
en el mensaje
news:

GenioMaestro,

Chequea el tema "Creating Indexes on Computed Columns" en los BOL.
Puede ser
que como calculas el valor a partir de multiples filas, esto hace
que la
funcion sea no determinista. Usa la funcion "objectproperty" para
comprobar
si la funcion es determinista y en caso de ser determinista verifica
si es
imprescisa, creo que en ese caso puedes usar la opcion "persisted"
cuando
creas la columna y sql server dejara crear un indice.

Creating Indexes on Computed Columns
http://msdn2.microsoft.com/en-us/li...89292.aspx

> SELECT TOP 1 COTIZACIONES.FECHA
> FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
> ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND
> COTIZACIONES.FECHA >>>>>>>> > CALCULOS.FECHA_CAL
> WHERE COTIZACIONES.COD_VALOR = @entra_valor AND
> .CALCULOS.FECHA_CAL IS
> NULL
> ORDER BY COTIZACIONES.FECHA ASC

A proposito, yo no usaria "left join" para comprobar existencia.
Usaria el
operador "exists" a cambio. De todas maneras prueba ambas versiones
a ver
cual te da mejor resultado. Tambien ve si tener un indice en
[COTIZACIONES]
por [COD_VALOR] ayuda a mejorar el plan de ejecucion.

SELECT TOP 1
c.FECHA
FROM
DBO.COTIZACIONES as a
WHERE
c.COD_VALOR = @entra_valor
and not exists (
select *
from DBO.CALCULOS as b
where
b.COD_VALOR = a.COD_VALOR
and b.FECHA_CAL = a.FECHA
)
ORDER BY
c.FECHA ASC
go


AMB

"GenioMaestro" wrote:

Y además, esta consulta tampoco me la paraleliza, tarda dos o tres
minutos
en darme la select con la columna calculada, porque la está
calculando al
vuelo, cada vez que la pido, y con el micro al 50%, claro.

Hay alguna manera de forzar al sql server 2005 para que paralelize
una
consulta????



"GenioMaestro" escribió en el mensaje
news:
> Va la funcion:
>
> ALTER FUNCTION [dbo].[FECHA_CAL_INI] (@entra_valor as INT)
> RETURNS DATETIME
> WITH SCHEMABINDING
> BEGIN
>
> RETURN (
> SELECT TOP 1 COTIZACIONES.FECHA
> FROM DBO.COTIZACIONES LEFT JOIN DBO.CALCULOS
> ON COTIZACIONES.COD_VALOR = CALCULOS.COD_VALOR AND
> COTIZACIONES.FECHA >>>>>>>> > CALCULOS.FECHA_CAL
> WHERE COTIZACIONES.COD_VALOR = @entra_valor AND
> .CALCULOS.FECHA_CAL IS
> NULL
> ORDER BY COTIZACIONES.FECHA ASC
> )
> END
>
> Gracias por el interes, Alejandro.
>
>
>
> "Alejandro Mesa"
> escribió en el
> mensaje
> news:
>> GenioMaestro,
>>
>> Pudieras mostrarnos la funcion?
>>
>>
>> AMB
>>
>> "GenioMaestro" wrote:
>>
>>> Hola:
>>>
>>> He creado una columna calculada en base a una funcion de
>>> usuario que
>>> funciona bien, pero es muy lenta.
>>>
>>> Cuando intento crear un indice sobre esa columna sql 2005 me
>>> dice:
>>>
>>> Mens. 2709, Nivel 16, Estado 1, Línea 1
>>> La columna 'F_CAL_INI' de tabla 'VALORES' no se puede usar en
>>> un índice
>>> o en
>>> estadísticas, o como una clave de partición, porque tiene
>>> acceso a datos
>>> del
>>> usuario o sistema.
>>>
>>> Alguien puede decirme a que es debido y como solucionarlo???
>>>
>>> Gracias
>>>
>>>
>>>
>
>