declarar text

Hola:
Una alternativa es leer bloques de la columna texto y llenar una
variable varchar/nvarchar que soportan hasta 8000 caracteres. Para hacer
esto NO incluyes en el cursor la variable y luego usando funciones (TEXTPTR,
READTEXT, WRITETEXT y PATINDEX) lees los datos y llenas la variable varchar,
procesas y luego vuelves a escribir. Es codigo feo y engorroso.
Si nos cuentas mas sobre lo que deseas hacer talvez podamos ayudarte, e
incluso ver si te ahorramos el cursor.
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.

Albertito escribio:

Hola a todos.
Tengo el siguiente problema: debo declarar un cursor sobre una tabla
que tiene un campo de tipo text.
Según tengo entendido se deben declarar las variables en forma local
sobre las cuales se volcará posteriormente el resultado de la select
del cursor. Pero me ha surgido el problema de que no se puede
declarar una variable de tipo text en modo local, por lo que existe
un conflicto con el campo de tipo text de la tabla que quiero leer.
¿Me equivoco en algún paso?, ¿existe alguna alternativa?, ...
Cualquier ayuda o sugerencia será bién recibida.

Gracias de antemano y un salduo.

Gracias Javier.
Supongo q con lo q me has contestado habrá suficiente.
La idea de lo q quiero hacer es la siguiente:
hacer un Trigger en una tabla de una base de datos para que cuando se
realice INSERT o UPDATE
se ejecute la misma acción en otra tabla idéntica q tengo en otra base de
datos. Para ello lo q hago es,
mediante un cursor, leo los registros obtenidos de SELECT * FROM INSERTED y
los añado en la otra tabla. Ahí es donde me ha surgido el problema del campo
Text

Si tienen otra sugerencia

Gracias de nuevo

"Javier Loria" escribió en el mensaje
news:

Hola:
Una alternativa es leer bloques de la columna texto y llenar una
variable varchar/nvarchar que soportan hasta 8000 caracteres. Para hacer
esto NO incluyes en el cursor la variable y luego usando funciones

(TEXTPTR,

READTEXT, WRITETEXT y PATINDEX) lees los datos y llenas la variable

varchar,

procesas y luego vuelves a escribir. Es codigo feo y engorroso.
Si nos cuentas mas sobre lo que deseas hacer talvez podamos ayudarte,

e

incluso ver si te ahorramos el cursor.
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.

Albertito escribio:
> Hola a todos.
> Tengo el siguiente problema: debo declarar un cursor sobre una tabla
> que tiene un campo de tipo text.
> Según tengo entendido se deben declarar las variables en forma local
> sobre las cuales se volcará posteriormente el resultado de la select
> del cursor. Pero me ha surgido el problema de que no se puede
> declarar una variable de tipo text en modo local, por lo que existe
> un conflicto con el campo de tipo text de la tabla que quiero leer.
> ¿Me equivoco en algún paso?, ¿existe alguna alternativa?, ...
> Cualquier ayuda o sugerencia será bién recibida.
>
> Gracias de antemano y un salduo.

Pero si lo único que necesitas es copiar los datos de una tabla a otra
dentro de un trigger, puedes usar un

INSERT [...]
SELECT * FROM INSERTED

en vez de un cursor...


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

Por favor, responder únicamente al foro
Se agradece la inclusión de sentencias DDL


"Albertito" escribió en el mensaje
news:#B$

Gracias Javier.
Supongo q con lo q me has contestado habrá suficiente.
La idea de lo q quiero hacer es la siguiente:
hacer un Trigger en una tabla de una base de datos para que cuando se
realice INSERT o UPDATE
se ejecute la misma acción en otra tabla idéntica q tengo en otra base de
datos. Para ello lo q hago es,
mediante un cursor, leo los registros obtenidos de SELECT * FROM INSERTED

y

los añado en la otra tabla. Ahí es donde me ha surgido el problema del

campo

Text

Si tienen otra sugerencia

Gracias de nuevo

"Javier Loria" escribió en el mensaje
news:
> Hola:
> Una alternativa es leer bloques de la columna texto y llenar una
> variable varchar/nvarchar que soportan hasta 8000 caracteres. Para hacer
> esto NO incluyes en el cursor la variable y luego usando funciones
(TEXTPTR,
> READTEXT, WRITETEXT y PATINDEX) lees los datos y llenas la variable
varchar,
> procesas y luego vuelves a escribir. Es codigo feo y engorroso.
> Si nos cuentas mas sobre lo que deseas hacer talvez podamos

ayudarte,

e
> incluso ver si te ahorramos el cursor.
> 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.
>
> Albertito escribio:
> > Hola a todos.
> > Tengo el siguiente problema: debo declarar un cursor sobre una tabla
> > que tiene un campo de tipo text.
> > Según tengo entendido se deben declarar las variables en forma local
> > sobre las cuales se volcará posteriormente el resultado de la select
> > del cursor. Pero me ha surgido el problema de que no se puede
> > declarar una variable de tipo text en modo local, por lo que existe
> > un conflicto con el campo de tipo text de la tabla que quiero leer.
> > ¿Me equivoco en algún paso?, ¿existe alguna alternativa?, ...
> > Cualquier ayuda o sugerencia será bién recibida.
> >
> > Gracias de antemano y un salduo.
>
>

En el caso del INSERT sí, pero cuando es un UPDATE no, ya que tengo que
identificar el registro modificado de la tabla de origen, localizarlo en la
tabla de destino y modificar todos los campos de ese registro (según lo
obtenido en SELECT * FROM INSERTED) para que exista una sincronización entre
ambas tablas.
Es por esto que debo obtener el campo de tipo Text, para luego hacer un
UPDATE TABLA SET CampoTipoText = ResultaTipoText , ... WHERE ...

Espero haberme explicado.
Gracias

Sigo sin ver la necesidad de usar un cursor para lo que necesitas... en
un trigger de actualización puedes identificar el registro modificado
también a partir de la tabla INSERTED (la tabla DELETED contendrá ese mismo
registro con los valores antiguos), y la instrucción UPDATE acepta la
cláusula FROM con su INNER correspondiente... Por ejemplo (extraído de los
BOL):

UPDATE titles
SET ytd_sales = t.ytd_sales + s.qty
FROM titles t, sales s
WHERE t.title_id = s.title_id
AND s.ord_date = (SELECT MAX(sales.ord_date) FROM sales)

En tu caso, "titles" sería la tabla que quieres actualizar y "sales" la
tabla virtual INSERTED. Haces el JOIN por el(los) campo(s) clave(s) y
listo...


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

Por favor, responder únicamente al foro
Se agradece la inclusión de sentencias DDL


"Albertito" escribió en el mensaje
news:

En el caso del INSERT sí, pero cuando es un UPDATE no, ya que tengo que
identificar el registro modificado de la tabla de origen, localizarlo en

la

tabla de destino y modificar todos los campos de ese registro (según lo
obtenido en SELECT * FROM INSERTED) para que exista una sincronización

entre

ambas tablas.
Es por esto que debo obtener el campo de tipo Text, para luego hacer un
UPDATE TABLA SET CampoTipoText = ResultaTipoText , ... WHERE ...

Espero haberme explicado.
Gracias