Identity en Variables tipo Table

ok de ser asi esta muy bien lo que estas haciendo.

Pregunta: cual es la necesidad de en una tabla de memoria resetiar un
Identity? y ese identity en esa tabla de memoria para que lo estan usando
exactamente? si se puede saber no?

Salu2

Maximiliano Damian Accotto


"Luis Cejas" escribió en el mensaje
news:

Maximiliano,
Ya hemos evaluado la relacion Costo/Beneficio de dicha tabla, igualmente

el

máximo de registros son 99 (de dos campos Tinyint)

Gracias,

Luis





Maximiliano D. A. escribió en mensaje ...
>Luis, si creas la tabla de forma en memoria como una variable no podes
>reiniciar el Identity como te mostre en el comando DBCC.
>
>ahora ojo con esto, que si la tabla pesa mucho consumiras mucha ram y eso
no
>es nada bueno, como siempre para cada caso hay que estudiar bien que
>solucion es mejor que cual
>
>Salu2
>
>Maximiliano Damian Accotto
>
>
>"Luis Cejas" escribió en el mensaje
>news:
>> Maximiliano: Muchas gracias igual.
>>
>> Isaías: Creo que hablamos de dos cosas diferentes.. con "create table
#XT"
>> lo que hago es crearla fisicamente en Tempdb y si de esa manera

funciona

>> como en cualquier tabla, pero con "Declare @XT Table" la creo en la
>memoria
>> del servidor.
>> Aclaro que el código fue simplemente de ejemplo para que entiendan mi
>> problema... lamento que no lo hayas entendido de esa manera.
>>
>> Gracias igual a todos.
>> Luis
>>
>>
>>
>>
>>
>> Isaías escribió en mensaje <049201c3dba9$1f4fb820$...
>> >Como dice Max, utilice el DBCC CHECKIDENT, aunque no le
>> >veo la logica al codigo, pero.
>> >
>> >Aunque aclaro, yo no lo hice con un DECLARE, si no con un
>> >CREATE
>> >
>> >create table #XT ( Ln Tinyint identity (1,1) , nLinea
>> >int )
>> >
>> >Insert #XT Values (1)
>> >Insert #XT Values (2)
>> >Insert #XT Values (3)
>> >Insert #XT Values (4)
>> >
>> >Select * from #XT
>> >Delete #XT
>> >dbcc checkident (#XT,RESEED, 4)
>> >Insert #XT Values (5)
>> >Select * from #XT
>> >
>>
>>
>
>

Maximiliano,
Ya hemos evaluado la relacion Costo/Beneficio de dicha tabla, igualmente el
máximo de registros son 99 (de dos campos Tinyint)

Gracias,

Luis





Maximiliano D. A. escribió en mensaje ...

Luis, si creas la tabla de forma en memoria como una variable no podes
reiniciar el Identity como te mostre en el comando DBCC.

ahora ojo con esto, que si la tabla pesa mucho consumiras mucha ram y eso

no

es nada bueno, como siempre para cada caso hay que estudiar bien que
solucion es mejor que cual

Salu2

Maximiliano Damian Accotto


"Luis Cejas" escribió en el mensaje
news:

Maximiliano: Muchas gracias igual.

Isaías: Creo que hablamos de dos cosas diferentes.. con "create table

#XT"

lo que hago es crearla fisicamente en Tempdb y si de esa manera funciona
como en cualquier tabla, pero con "Declare @XT Table" la creo en la

memoria

del servidor.
Aclaro que el código fue simplemente de ejemplo para que entiendan mi
problema... lamento que no lo hayas entendido de esa manera.

Gracias igual a todos.
Luis





Isaías escribió en mensaje <049201c3dba9$1f4fb820$...
>Como dice Max, utilice el DBCC CHECKIDENT, aunque no le
>veo la logica al codigo, pero.
>
>Aunque aclaro, yo no lo hice con un DECLARE, si no con un
>CREATE
>
>create table #XT ( Ln Tinyint identity (1,1) , nLinea
>int )
>
>Insert #XT Values (1)
>Insert #XT Values (2)
>Insert #XT Values (3)
>Insert #XT Values (4)
>
>Select * from #XT
>Delete #XT
>dbcc checkident (#XT,RESEED, 4)
>Insert #XT Values (5)
>Select * from #XT
>

Por ahi hubieramos empezado, tal vez el saber ¿Que desea
hacer?, resuelva el crear o no, una tabla en RAM o crearla
temporal.

Saludos.

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.

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.
>
>