Gestion de tablas locales ('#') - TEMPDB

Hola, es que si la creo local solamente la podra ver ese alcance, como
seguro q abren la conexion y la crean ahi, esa sola conexion puede ver esa
tabla.
Entonces la opcion seria que la hagan global ##


Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Fernando Mosquera Catarecha" escribió en el
mensaje de noticias:#

Estimado Maxi,

Es correcta tu apreciación, sinceramente peco por no explayarme tanto en
tecnicismo, agradezco tus comentarios.

Se te ocurre alguna idea que aporte claridad a mi problema?



Muchas gracias,

Atte.

Fernando.


"Maxi Accotto" wrote in message
news:

Hola amigo, lamento decirte que no es correcto lo que estas comentando
:(, tablas temporales hay 2 (globales y locales) las primeras se
identifican por usar ## y las segundas por uno #, pero, estas ultimas NO
estan vivas durante una sesion sino que en un alcance determinado (por
ejemplo lo que viva un Store), las segundas si viven durante toda la
sesion.
Aqui expongo un ejemplo para demostrar lo que comento:

USE NORTHWIND
GO

CREATE PROC USP_1 AS
CREATE TABLE #T1 (ID INT)
INSERT INTO #T1 VALUES (1)
SELECT * FROM #T1
GO

EXEC USP_1
SELECT * FROM #T1 -- FALLA

CREATE PROC USP_2 AS
CREATE TABLE ##T2 (ID INT)
INSERT INTO ##T2 VALUES (1)
SELECT * FROM ##T2
GO

EXEC USP_2
SELECT * FROM ##T2 -- NO FALLA



Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"jcac" escribió en el mensaje de
noticias:

Solo como dato informativo las tablas temporales de # solo se crean por
sesión, es decir que si una sesión crea una tabla #tmp y otra sesión
crea la table #tmp estas serán distintas, ya que he visto que las crea
como #tmp___________________________________<codificacion adicional>
dentro de la TempDB.

No se si eso es lo que te confunda pero bueno solo como dato informativo

Saludos

"Fernando Mosquera Catarecha" escribió en el
mensaje news:OAT$

Buenos días a todos!



Se me planteo la siguiente problemática:



Como es sabido, cuando un usuario crea una tabla temporal local (con el
signo '#') esta se almacena en el contendor TEMPDB de nuestro motor de
SQL. Hasta que el usuario no realiza un DROP de la misma o no cierra la
conexión dicha tabla no es eliminada.



Ahora bien:



Como puedo eliminar dicha tabla?

Como puedo realizarle un SELECT de la misma?

Como puedo saber que conexión la esta manteniendo?



Realice toda clase de pruebas / scripts involucrando el object id,
name, tablas del sistema, etc. y no puede obtener resultados positivo.



No puedo concebir que siendo sysadmin no pueda tener gestión sobre
dichas tablas.



Si alguien ya se planteo esta problemática o tiene una solución que yo
ignoro le agradecería que conteste el Post.



Saludos Cordiales,

Atte.

Fernando.

Correcto Maxi, pero yo como administrador tendría que poder gestionar estas
tablas.

Minimamente poder borrarlas o algo mas básico aun como identificar la
conexión que la mantiene.



Agradecería cualquier aporte,

Muchas gracias.

Atte.

Fernando.


"Maxi Accotto" wrote in message
news:

Hola, es que si la creo local solamente la podra ver ese alcance, como
seguro q abren la conexion y la crean ahi, esa sola conexion puede ver esa
tabla.
Entonces la opcion seria que la hagan global ##


Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Fernando Mosquera Catarecha" escribió en el
mensaje de noticias:#

Estimado Maxi,

Es correcta tu apreciación, sinceramente peco por no explayarme tanto en
tecnicismo, agradezco tus comentarios.

Se te ocurre alguna idea que aporte claridad a mi problema?



Muchas gracias,

Atte.

Fernando.


"Maxi Accotto" wrote in message
news:

Hola amigo, lamento decirte que no es correcto lo que estas comentando
:(, tablas temporales hay 2 (globales y locales) las primeras se
identifican por usar ## y las segundas por uno #, pero, estas ultimas NO
estan vivas durante una sesion sino que en un alcance determinado (por
ejemplo lo que viva un Store), las segundas si viven durante toda la
sesion.
Aqui expongo un ejemplo para demostrar lo que comento:

USE NORTHWIND
GO

CREATE PROC USP_1 AS
CREATE TABLE #T1 (ID INT)
INSERT INTO #T1 VALUES (1)
SELECT * FROM #T1
GO

EXEC USP_1
SELECT * FROM #T1 -- FALLA

CREATE PROC USP_2 AS
CREATE TABLE ##T2 (ID INT)
INSERT INTO ##T2 VALUES (1)
SELECT * FROM ##T2
GO

EXEC USP_2
SELECT * FROM ##T2 -- NO FALLA



Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"jcac" escribió en el mensaje de
noticias:

Solo como dato informativo las tablas temporales de # solo se crean por
sesión, es decir que si una sesión crea una tabla #tmp y otra sesión
crea la table #tmp estas serán distintas, ya que he visto que las crea
como #tmp___________________________________<codificacion adicional>
dentro de la TempDB.

No se si eso es lo que te confunda pero bueno solo como dato
informativo

Saludos

"Fernando Mosquera Catarecha" escribió en el
mensaje news:OAT$

Buenos días a todos!



Se me planteo la siguiente problemática:



Como es sabido, cuando un usuario crea una tabla temporal local (con
el signo '#') esta se almacena en el contendor TEMPDB de nuestro motor
de SQL. Hasta que el usuario no realiza un DROP de la misma o no
cierra la conexión dicha tabla no es eliminada.



Ahora bien:



Como puedo eliminar dicha tabla?

Como puedo realizarle un SELECT de la misma?

Como puedo saber que conexión la esta manteniendo?



Realice toda clase de pruebas / scripts involucrando el object id,
name, tablas del sistema, etc. y no puede obtener resultados positivo.



No puedo concebir que siendo sysadmin no pueda tener gestión sobre
dichas tablas.



Si alguien ya se planteo esta problemática o tiene una solución que yo
ignoro le agradecería que conteste el Post.



Saludos Cordiales,

Atte.

Fernando.

Cuidado Maxi que desde el stored, si puedes ver tablas temporales creadas
fuera de el; ¿qué pasaría si abres conexión, creas una tabla temporal, y a
continuación comienzas a hacer llamadas al sp? la tabla temporal está en el
ámbito de su sesión, y podrá ser vista por cualquier llamada de sps:

use northwind
go

create proc usp_1 as
insert into #t1 values ('estoy dentro')
select * from #t1
go

create table #t1 (valor char(15));
insert into #t1 values ('estoy fuera')
exec usp_1; -- no falla


Resultado:

valor

estoy fuera
estoy dentro



no es frecuente, pero yo he estado en algún cliente que necesitaba. El
escenario era el siguiente: no utilizaban connection pooling (muy pocas
conexiones), y necesitaban al conectarse a la aplicación, cargar en una
tabla valores asociados al usuario (temas de seguridad) para usarlos en las
sucesivas consultas al sistema; la solución era, nada más conectarse (al
hacer connetion.Open();), crear un SqlCommand que ejecutara la creación de
la tabla temporal, e insertaba los valores que necesitaba mediante batch,
nada de llamada a procedimienot almacenado. Sucesivos accesos a la base de
datos (fuera SP, o fuera batch) podían ver la tabla temporal de la sesión.



Saludos,

Eladio Rincón,
SQL Server MVP
http://blogs.solidq.com/es/elrincondeldba

"Maxi Accotto" wrote in message
news:

Hola amigo, lamento decirte que no es correcto lo que estas comentando :(,
tablas temporales hay 2 (globales y locales) las primeras se identifican
por usar ## y las segundas por uno #, pero, estas ultimas NO estan vivas
durante una sesion sino que en un alcance determinado (por ejemplo lo que
viva un Store), las segundas si viven durante toda la sesion.
Aqui expongo un ejemplo para demostrar lo que comento:

USE NORTHWIND
GO

CREATE PROC USP_1 AS
CREATE TABLE #T1 (ID INT)
INSERT INTO #T1 VALUES (1)
SELECT * FROM #T1
GO

EXEC USP_1
SELECT * FROM #T1 -- FALLA

CREATE PROC USP_2 AS
CREATE TABLE ##T2 (ID INT)
INSERT INTO ##T2 VALUES (1)
SELECT * FROM ##T2
GO

EXEC USP_2
SELECT * FROM ##T2 -- NO FALLA



Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"jcac" escribió en el mensaje de
noticias:

Solo como dato informativo las tablas temporales de # solo se crean por
sesión, es decir que si una sesión crea una tabla #tmp y otra sesión crea
la table #tmp estas serán distintas, ya que he visto que las crea como
#tmp___________________________________<codificacion adicional> dentro de
la TempDB.

No se si eso es lo que te confunda pero bueno solo como dato informativo

Saludos

"Fernando Mosquera Catarecha" escribió en el
mensaje news:OAT$

Buenos días a todos!



Se me planteo la siguiente problemática:



Como es sabido, cuando un usuario crea una tabla temporal local (con el
signo '#') esta se almacena en el contendor TEMPDB de nuestro motor de
SQL. Hasta que el usuario no realiza un DROP de la misma o no cierra la
conexión dicha tabla no es eliminada.



Ahora bien:



Como puedo eliminar dicha tabla?

Como puedo realizarle un SELECT de la misma?

Como puedo saber que conexión la esta manteniendo?



Realice toda clase de pruebas / scripts involucrando el object id, name,
tablas del sistema, etc. y no puede obtener resultados positivo.



No puedo concebir que siendo sysadmin no pueda tener gestión sobre
dichas tablas.



Si alguien ya se planteo esta problemática o tiene una solución que yo
ignoro le agradecería que conteste el Post.



Saludos Cordiales,

Atte.

Fernando.

Hola Eladio, si eso si, quizas no me explique bien, pero lo que queria yo
mostrar es que las locales tienen un alcance y mueren, si la creas fuera del
SP las ves, pero si las creas dentro no las ves desde afuera. Pero vale
mucho tu ejemplo como para aclarar mas aun ya que en tu caso el alcance no
murio porque esta en la misma conexion


Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Eladio Rincón" escribió en el mensaje de
noticias:#

Cuidado Maxi que desde el stored, si puedes ver tablas temporales creadas
fuera de el; ¿qué pasaría si abres conexión, creas una tabla temporal, y a
continuación comienzas a hacer llamadas al sp? la tabla temporal está en
el ámbito de su sesión, y podrá ser vista por cualquier llamada de sps:

use northwind
go

create proc usp_1 as
insert into #t1 values ('estoy dentro')
select * from #t1
go

create table #t1 (valor char(15));
insert into #t1 values ('estoy fuera')
exec usp_1; -- no falla


Resultado:

valor

estoy fuera
estoy dentro



no es frecuente, pero yo he estado en algún cliente que necesitaba. El
escenario era el siguiente: no utilizaban connection pooling (muy pocas
conexiones), y necesitaban al conectarse a la aplicación, cargar en una
tabla valores asociados al usuario (temas de seguridad) para usarlos en
las sucesivas consultas al sistema; la solución era, nada más conectarse
(al hacer connetion.Open();), crear un SqlCommand que ejecutara la
creación de la tabla temporal, e insertaba los valores que necesitaba
mediante batch, nada de llamada a procedimienot almacenado. Sucesivos
accesos a la base de datos (fuera SP, o fuera batch) podían ver la tabla
temporal de la sesión.



Saludos,

Eladio Rincón,
SQL Server MVP
http://blogs.solidq.com/es/elrincondeldba

"Maxi Accotto" wrote in message
news:

Hola amigo, lamento decirte que no es correcto lo que estas comentando
:(, tablas temporales hay 2 (globales y locales) las primeras se
identifican por usar ## y las segundas por uno #, pero, estas ultimas NO
estan vivas durante una sesion sino que en un alcance determinado (por
ejemplo lo que viva un Store), las segundas si viven durante toda la
sesion.
Aqui expongo un ejemplo para demostrar lo que comento:

USE NORTHWIND
GO

CREATE PROC USP_1 AS
CREATE TABLE #T1 (ID INT)
INSERT INTO #T1 VALUES (1)
SELECT * FROM #T1
GO

EXEC USP_1
SELECT * FROM #T1 -- FALLA

CREATE PROC USP_2 AS
CREATE TABLE ##T2 (ID INT)
INSERT INTO ##T2 VALUES (1)
SELECT * FROM ##T2
GO

EXEC USP_2
SELECT * FROM ##T2 -- NO FALLA



Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"jcac" escribió en el mensaje de
noticias:

Solo como dato informativo las tablas temporales de # solo se crean por
sesión, es decir que si una sesión crea una tabla #tmp y otra sesión
crea la table #tmp estas serán distintas, ya que he visto que las crea
como #tmp___________________________________<codificacion adicional>
dentro de la TempDB.

No se si eso es lo que te confunda pero bueno solo como dato informativo

Saludos

"Fernando Mosquera Catarecha" escribió en el
mensaje news:OAT$

Buenos días a todos!



Se me planteo la siguiente problemática:



Como es sabido, cuando un usuario crea una tabla temporal local (con el
signo '#') esta se almacena en el contendor TEMPDB de nuestro motor de
SQL. Hasta que el usuario no realiza un DROP de la misma o no cierra la
conexión dicha tabla no es eliminada.



Ahora bien:



Como puedo eliminar dicha tabla?

Como puedo realizarle un SELECT de la misma?

Como puedo saber que conexión la esta manteniendo?



Realice toda clase de pruebas / scripts involucrando el object id,
name, tablas del sistema, etc. y no puede obtener resultados positivo.



No puedo concebir que siendo sysadmin no pueda tener gestión sobre
dichas tablas.



Si alguien ya se planteo esta problemática o tiene una solución que yo
ignoro le agradecería que conteste el Post.



Saludos Cordiales,

Atte.

Fernando.

Amigos, no puedo concebir que un DBA no pueda tener control de las tablas
temporales locales..



Retomo las preguntas claves:



Como puedo eliminar una tabla temporal local que creo una conexión aun
activa? (sin hacer el KILL al PID de la conexión).



Como puedo saber que conexión la esta manteniendo? (a fin de hacer KILL al
PID de la conexión).



Como puedo realizarle un SELECT de dicha tabla? (esto no es tan relevante
como las dos anteriores).



Por favor si alguien puede aportar un poco de claridad al asunto,

Muchas gracias a todos!

Saludos cordiales,

Atte.

Fernando.



"Fernando Mosquera Catarecha" wrote in message
news:OAT$

Buenos días a todos!



Se me planteo la siguiente problemática:



Como es sabido, cuando un usuario crea una tabla temporal local (con el
signo '#') esta se almacena en el contendor TEMPDB de nuestro motor de
SQL. Hasta que el usuario no realiza un DROP de la misma o no cierra la
conexión dicha tabla no es eliminada.



Ahora bien:



Como puedo eliminar dicha tabla?

Como puedo realizarle un SELECT de la misma?

Como puedo saber que conexión la esta manteniendo?



Realice toda clase de pruebas / scripts involucrando el object id, name,
tablas del sistema, etc. y no puede obtener resultados positivo.



No puedo concebir que siendo sysadmin no pueda tener gestión sobre dichas
tablas.



Si alguien ya se planteo esta problemática o tiene una solución que yo
ignoro le agradecería que conteste el Post.



Saludos Cordiales,

Atte.

Fernando.