Identity en Variables tipo Table

La desventaja de esta opcion es que si quiero llenar la tabla desde un
SELECT no tendre la autonumeracion, teniendo que crear un cursor luego

para

modificar esta columna en forma manual.

No necesariamente, siempre en un select puedes simular le contador y obtener
el mismo resultado

Saludos,

Norman



"Adrian Garcia" wrote in message
news:%

Bien, como hemos visto no hay forma conocida por nosotros de hacer el

RESEED

de una tabla temporal en memoria, que opciones hay?
a) Utilizar tablas temporales en la TEMPDB mediante el CREATE TABLE #
En ese caso no habria problemas, pero seguramenteel rendimiento se vera
afectado ya que las mismas son mas pesadas que las de memoria.
b) No definir la propiedad identity e ir asignado los valores de las
columnas por medio de un contador/variable que podamos manipular sin
problemas. Esto seguramente significara escribir mas codigo T-SQL pero la
verdad es que es muy simple.
DECLARE @contador INT

SET @contador = 1

INSERT INTO Tab(nrosec, ...)
VALUES (@contador, .)
La desventaja de esta opcion es que si quiero llenar la tabla desde un
SELECT no tendre la autonumeracion, teniendo que crear un cursor luego

para

modificar esta columna en forma manual.

Quizas a alguien se le ocurra alguna otra solucion a este problema.

Saludos
Adrian D. Garcia
NDSoft
SET @contador = @contador + 1

"Mario Cejas" wrote in message
news:e$
> Tratare de explicar someramente el problema del seed..
>
> Te cuento que estamos desarrollando un sistema de reservas como
> SABRE,AMADEUS,RECIBER,Luftansa Systems , etc,etc,etc.
> El problema surge en la divicion de un PNR (Passenger Name

Record).

> En un PNR tenes por ejemplo los campos Contactos y Remarks que pueden o
no
> estar asosiados a algun pasajero de la reserva:
> Ejemplo:
> PNR SIN DIVIDIR
> 1.1CASTRO/R
> 2.1ABAURREA/G
> 3.1PEREZ/W
> 1 XX4330Y 20JAN MA AEPMDQ KL3 18:00 19:00
> TKT/OK
> PHONES
> 1- 54-11-4422-1200*/P1
> 2- 54-11-4560-0000 TELEFONO DEL HOTEL
> REMARKS
> 1- RETIRAN LOS VOUCHERS EN EL HOTEL*/P2-3
> 2- NO HACE EL CIRCUITO DE CATARATAS DEL IGUAZU*/P1
> RECEIVED FROM - PAX
> BUE.BUEXX-MM 1506/06JAN04 *OWLYSF -H
> El proceso de divicion del pasajero 1 genera 2 PNR en el
cual
> solo los PHONES y REMARKS del pasjero 1 y los comunes a todos,

pasaran

al
> PNR Hijo. Y en el PNR Original quedaran los PHONES y REMARKS de los
> pasajeros 2 y 3 mas los comunes a todos. El */Pn al final de las lineas
> indica a que pasajero esta asosiada la linea.
> Quiere decir que la linea 1 de PHONES pertenece solo al pax
> 1(1CASTRO/R) y la Linea 2 pertenece a los tres pax. Encambio en la linea

1

> de REMARKS pertenece a los pasajeros 2 y 3 y la linea 2 al pax 1.NO HAY
en
> este caso un remark en comun que pertenezca a los tres pasajeros.
>
> La tabla temporal y en memoria se usa para renumerar las lineas

asociadas

a
> los NOMBRES de los campos PHONES y REMARKS del PNR a DIVIDIR con LOS

PNR

> PADRE e HIJO generados.
> Ya que los PNR divididos quedan de esta manera.
> **** PNR HIJO
> 1.1CASTRO/R
> 1 XX4330Y 20JAN TU AEPMDQ KL1 18:00 19:00
> TKT/OK
> PHONES
> 1- 54-11-4422-1200*/P1
> 2- 54-11-4560-0000 TELEFONO DEL HOTEL
> REMARKS
> 1- NO HACE EL CIRCUITO DE CATARATAS DEL IGUAZU*/P1
> 2-»» SPLIT BY AEP.AEPXX-MC 1448/16ENE04-OWLYSF
>
> *** PNR PADRE
> 1.1ABAURREA/G
> 2.1PEREZ/W
> 1 XX4330Y 20JAN TU AEPMDQ KL2 18:00 19:00
> TKT/OK
> PHONES
> 1- 54-11-4560-0000 TELEFONO DEL HOTEL
> REMARKS
> 1- RETIRAN LOS VOUCHERS EN EL HOTEL*/P1-2
> RECEIVED FROM - PAX
> BUE.BUEXX-MM 1506/06JAN04 *OWLYSF -H
>
> Notamos que, obviamente, la solucion mas rapida es mantener
dos
> tablas temporales en memoria con un identity para la nueva linea y un
> campo tinyint con el valor de la lineas originales .
> Declare @XTPadreTemp Table ( Ln Tinyint identity (1,1) , nPax
Tinyint )
> Declare @XTHijoTemp Table ( Ln Tinyint identity (1,1) , nPax
Tinyint )
> Es por eso que despues de actualizar uno de los campos (PHONES) y

comienza

> el proceso de actualizacion de REMARKS deberia poner a cero el identity
para
> cargar las lineas asociadas al campo Remarks.
> El ejemplo dado en la pregunta original de Luis fue muy somero

debido

a
> la complejidad del uso real. Espero que les haya aclarado algo(aunque

creo

> que no) gracias igual a los dos.
>
> Saludos:
> Mario
>
>
> "Isaías" escribió en el mensaje
> news:0c2701c3dbce$80acf3b0$
> Por ahi hubieramos empezado, tal vez el saber ¿Que desea
> hacer?, resuelva el crear o no, una tabla en RAM o crearla
> temporal.
>
> Saludos.
>
>

Bien, como hemos visto no hay forma conocida por nosotros de hacer el RESEED
de una tabla temporal en memoria, que opciones hay?
a) Utilizar tablas temporales en la TEMPDB mediante el CREATE TABLE #
En ese caso no habria problemas, pero seguramenteel rendimiento se vera
afectado ya que las mismas son mas pesadas que las de memoria.
b) No definir la propiedad identity e ir asignado los valores de las
columnas por medio de un contador/variable que podamos manipular sin
problemas. Esto seguramente significara escribir mas codigo T-SQL pero la
verdad es que es muy simple.
DECLARE @contador INT

SET @contador = 1

INSERT INTO Tab(nrosec, ...)
VALUES (@contador, .)
La desventaja de esta opcion es que si quiero llenar la tabla desde un
SELECT no tendre la autonumeracion, teniendo que crear un cursor luego para
modificar esta columna en forma manual.

Quizas a alguien se le ocurra alguna otra solucion a este problema.

Saludos
Adrian D. Garcia
NDSoft
SET @contador = @contador + 1

"Mario Cejas" wrote in message
news:e$

Tratare de explicar someramente el problema del seed..

Te cuento que estamos desarrollando un sistema de reservas como
SABRE,AMADEUS,RECIBER,Luftansa Systems , etc,etc,etc.
El problema surge en la divicion de un PNR (Passenger Name Record).
En un PNR tenes por ejemplo los campos Contactos y Remarks que pueden o

no

estar asosiados a algun pasajero de la reserva:
Ejemplo:
PNR SIN DIVIDIR
1.1CASTRO/R
2.1ABAURREA/G
3.1PEREZ/W
1 XX4330Y 20JAN MA AEPMDQ KL3 18:00 19:00
TKT/OK
PHONES
1- 54-11-4422-1200*/P1
2- 54-11-4560-0000 TELEFONO DEL HOTEL
REMARKS
1- RETIRAN LOS VOUCHERS EN EL HOTEL*/P2-3
2- NO HACE EL CIRCUITO DE CATARATAS DEL IGUAZU*/P1
RECEIVED FROM - PAX
BUE.BUEXX-MM 1506/06JAN04 *OWLYSF -H
El proceso de divicion del pasajero 1 genera 2 PNR en el

cual

solo los PHONES y REMARKS del pasjero 1 y los comunes a todos, pasaran

al

PNR Hijo. Y en el PNR Original quedaran los PHONES y REMARKS de los
pasajeros 2 y 3 mas los comunes a todos. El */Pn al final de las lineas
indica a que pasajero esta asosiada la linea.
Quiere decir que la linea 1 de PHONES pertenece solo al pax
1(1CASTRO/R) y la Linea 2 pertenece a los tres pax. Encambio en la linea 1
de REMARKS pertenece a los pasajeros 2 y 3 y la linea 2 al pax 1.NO HAY

en

este caso un remark en comun que pertenezca a los tres pasajeros.

La tabla temporal y en memoria se usa para renumerar las lineas asociadas

a

los NOMBRES de los campos PHONES y REMARKS del PNR a DIVIDIR con LOS PNR
PADRE e HIJO generados.
Ya que los PNR divididos quedan de esta manera.
**** PNR HIJO
1.1CASTRO/R
1 XX4330Y 20JAN TU AEPMDQ KL1 18:00 19:00
TKT/OK
PHONES
1- 54-11-4422-1200*/P1
2- 54-11-4560-0000 TELEFONO DEL HOTEL
REMARKS
1- NO HACE EL CIRCUITO DE CATARATAS DEL IGUAZU*/P1
2-»» SPLIT BY AEP.AEPXX-MC 1448/16ENE04-OWLYSF

*** PNR PADRE
1.1ABAURREA/G
2.1PEREZ/W
1 XX4330Y 20JAN TU AEPMDQ KL2 18:00 19:00
TKT/OK
PHONES
1- 54-11-4560-0000 TELEFONO DEL HOTEL
REMARKS
1- RETIRAN LOS VOUCHERS EN EL HOTEL*/P1-2
RECEIVED FROM - PAX
BUE.BUEXX-MM 1506/06JAN04 *OWLYSF -H

Notamos que, obviamente, la solucion mas rapida es mantener

dos

tablas temporales en memoria con un identity para la nueva linea y un
campo tinyint con el valor de la lineas originales .
Declare @XTPadreTemp Table ( Ln Tinyint identity (1,1) , nPax

Tinyint )

Declare @XTHijoTemp Table ( Ln Tinyint identity (1,1) , nPax

Tinyint )

Es por eso que despues de actualizar uno de los campos (PHONES) y comienza
el proceso de actualizacion de REMARKS deberia poner a cero el identity

para

cargar las lineas asociadas al campo Remarks.
El ejemplo dado en la pregunta original de Luis fue muy somero debido

a

la complejidad del uso real. Espero que les haya aclarado algo(aunque creo
que no) gracias igual a los dos.

Saludos:
Mario


"Isaías" escribió en el mensaje
news:0c2701c3dbce$80acf3b0$
Por ahi hubieramos empezado, tal vez el saber ¿Que desea
hacer?, resuelva el crear o no, una tabla en RAM o crearla
temporal.

Saludos.

Perfecto!

"Mario Cejas" wrote in message
news:

Adrian: Muchas Gracias por la rta.
Te cuento que momentaneamente lo solucionamos con una variable que

toma

el valor de count antes de vaciar la tabla de memoria. Para asi tener la
nuva base de la identidad
.
.
...
.
select @nBasePadre = Count (ln) from @XTPadreTemp
select @nBaseHijo = Count (ln) from @XTHijoTemp
Delete from @XTPadreTemp
Delete from @XTHijoTemp

Insert Into @XTPadreTemp


Entonces en Ln - @nBasePadre me da la nueva Identidad.

Gracias
Mario

"Adrian Garcia" escribió en el mensaje
news:%
> Bien, como hemos visto no hay forma conocida por nosotros de hacer el
RESEED
> de una tabla temporal en memoria, que opciones hay?
> a) Utilizar tablas temporales en la TEMPDB mediante el CREATE TABLE #

> En ese caso no habria problemas, pero seguramenteel rendimiento se vera
> afectado ya que las mismas son mas pesadas que las de memoria.
> b) No definir la propiedad identity e ir asignado los valores de las
> columnas por medio de un contador/variable que podamos manipular sin
> problemas. Esto seguramente significara escribir mas codigo T-SQL pero

la

> verdad es que es muy simple.
> DECLARE @contador INT
>
> SET @contador = 1
>
> INSERT INTO Tab(nrosec, ...)
> VALUES (@contador, .)
> La desventaja de esta opcion es que si quiero llenar la tabla desde un
> SELECT no tendre la autonumeracion, teniendo que crear un cursor luego
para
> modificar esta columna en forma manual.
>
> Quizas a alguien se le ocurra alguna otra solucion a este problema.
>
> Saludos
> Adrian D. Garcia
> NDSoft
> SET @contador = @contador + 1
>
> "Mario Cejas" wrote in message
> news:e$
> > Tratare de explicar someramente el problema del seed..
> >
> > Te cuento que estamos desarrollando un sistema de reservas como
> > SABRE,AMADEUS,RECIBER,Luftansa Systems , etc,etc,etc.
> > El problema surge en la divicion de un PNR (Passenger Name
Record).
> > En un PNR tenes por ejemplo los campos Contactos y Remarks que pueden

o

> no
> > estar asosiados a algun pasajero de la reserva:
> > Ejemplo:
> > PNR SIN DIVIDIR
> > 1.1CASTRO/R
> > 2.1ABAURREA/G
> > 3.1PEREZ/W
> > 1 XX4330Y 20JAN MA AEPMDQ KL3 18:00 19:00
> > TKT/OK
> > PHONES
> > 1- 54-11-4422-1200*/P1
> > 2- 54-11-4560-0000 TELEFONO DEL HOTEL
> > REMARKS
> > 1- RETIRAN LOS VOUCHERS EN EL HOTEL*/P2-3
> > 2- NO HACE EL CIRCUITO DE CATARATAS DEL IGUAZU*/P1
> > RECEIVED FROM - PAX
> > BUE.BUEXX-MM 1506/06JAN04 *OWLYSF -H
> > El proceso de divicion del pasajero 1 genera 2 PNR en el
> cual
> > solo los PHONES y REMARKS del pasjero 1 y los comunes a todos,
pasaran
> al
> > PNR Hijo. Y en el PNR Original quedaran los PHONES y REMARKS de los
> > pasajeros 2 y 3 mas los comunes a todos. El */Pn al final de las

lineas

> > indica a que pasajero esta asosiada la linea.
> > Quiere decir que la linea 1 de PHONES pertenece solo al pax
> > 1(1CASTRO/R) y la Linea 2 pertenece a los tres pax. Encambio en la

linea

1
> > de REMARKS pertenece a los pasajeros 2 y 3 y la linea 2 al pax 1.NO

HAY

> en
> > este caso un remark en comun que pertenezca a los tres pasajeros.
> >
> > La tabla temporal y en memoria se usa para renumerar las lineas
asociadas
> a
> > los NOMBRES de los campos PHONES y REMARKS del PNR a DIVIDIR con LOS
PNR
> > PADRE e HIJO generados.
> > Ya que los PNR divididos quedan de esta manera.
> > **** PNR HIJO
> > 1.1CASTRO/R
> > 1 XX4330Y 20JAN TU AEPMDQ KL1 18:00 19:00
> > TKT/OK
> > PHONES
> > 1- 54-11-4422-1200*/P1
> > 2- 54-11-4560-0000 TELEFONO DEL HOTEL
> > REMARKS
> > 1- NO HACE EL CIRCUITO DE CATARATAS DEL IGUAZU*/P1
> > 2-»» SPLIT BY AEP.AEPXX-MC 1448/16ENE04-OWLYSF
> >
> > *** PNR PADRE
> > 1.1ABAURREA/G
> > 2.1PEREZ/W
> > 1 XX4330Y 20JAN TU AEPMDQ KL2 18:00 19:00
> > TKT/OK
> > PHONES
> > 1- 54-11-4560-0000 TELEFONO DEL HOTEL
> > REMARKS
> > 1- RETIRAN LOS VOUCHERS EN EL HOTEL*/P1-2
> > RECEIVED FROM - PAX
> > BUE.BUEXX-MM 1506/06JAN04 *OWLYSF -H
> >
> > Notamos que, obviamente, la solucion mas rapida es

mantener

> dos
> > tablas temporales en memoria con un identity para la nueva linea y

un

> > campo tinyint con el valor de la lineas originales .
> > Declare @XTPadreTemp Table ( Ln Tinyint identity (1,1) , nPax
> Tinyint )
> > Declare @XTHijoTemp Table ( Ln Tinyint identity (1,1) , nPax
> Tinyint )
> > Es por eso que despues de actualizar uno de los campos (PHONES) y
comienza
> > el proceso de actualizacion de REMARKS deberia poner a cero el

identity

> para
> > cargar las lineas asociadas al campo Remarks.
> > El ejemplo dado en la pregunta original de Luis fue muy somero
debido
> a
> > la complejidad del uso real. Espero que les haya aclarado algo(aunque
creo
> > que no) gracias igual a los dos.
> >
> > Saludos:
> > Mario
> >
> >
> > "Isaías" escribió en el mensaje
> > news:0c2701c3dbce$80acf3b0$
> > Por ahi hubieramos empezado, tal vez el saber ¿Que desea
> > hacer?, resuelva el crear o no, una tabla en RAM o crearla
> > temporal.
> >
> > Saludos.
> >
> >
>
>