2009-06-01 16 views
52

¿Hay alguna forma de persistir en una variable a lo largo de un intento?¿Hay alguna manera de persistir en una variable a lo largo de un intento?

Declare @bob as varchar(50); 
Set @bob = 'SweetDB'; 
GO 
USE @bob --- see note below 
GO 
INSERT INTO @bob.[dbo].[ProjectVersion] ([DB_Name], [Script]) VALUES (@bob,'1.2') 

Ver esta pregunta SO para la línea 'USO @bob'.

+0

¿Por qué te ¿Necesita calificar el nombre de la tabla con el nombre de la base de datos?Supongo que se hizo una pregunta similar antes de esta. – shahkalpesh

+0

Y no hay forma de calificar los nombres de tabla con el nombre de la base de datos en una variable como esa. Con su pregunta anterior sobre el uso de una variable con la declaración USE, supongo que tendrá que hacer todo en SQL dinámico, con todo el dolor que arrastra a la mesa. –

+0

El script actual integra 4 bases de datos diferentes. He comentado instrucciones para encontrar y reemplazar dbName1, dbName2, dbName3 y dbName4. Solo pensé que sería menos propenso a errores para el cliente solo establecer cuatro variables. – NitroxDM

Respuesta

25

El comando go se utiliza para dividir el código en lotes separados. Si eso es exactamente lo que quiere hacer, entonces debe usarlo, pero significa que los lotes están realmente separados, y no puede compartir variables entre ellos.

En su caso, la solución es simple; simplemente puede eliminar las declaraciones go, no son necesarias en ese código.

Nota al margen: No se puede usar una variable en una declaración use, tiene que ser el nombre de una base de datos.

+0

Algunas declaraciones SQL deben ser la primera instrucción en un bloque (la región entre las declaraciones GO). Por ejemplo: CREATE PROCEDURE o CREATE FUNCTION deben ocurrir antes que cualquier otra declaración, ya sea en la parte superior de la secuencia de comandos o inmediatamente después de la instrucción GO (nota: el espacio en blanco y los comentarios están permitidos antes de estas declaraciones). Al ejecutar scripts donde tales declaraciones deben ocurrir después de otra lógica, se requieren las sentencias GO. Pero debo aceptar que en la mayoría de los casos, las declaraciones GO se pueden eliminar. – Zarepheth

+0

@Zarepheth: Buen punto. No es necesario en este código específico, pero es útil saber que podrían ser necesarios en algunos casos. – Guffa

+1

¿Por qué el voto a favor? Si no explica qué es lo que cree que está mal, no puede mejorar la respuesta. – Guffa

1

No estoy seguro, si esto ayuda

declare @s varchar(50) 
set @s='Northwind' 

declare @t nvarchar(100) 
set @t = 'select * from ' + @s + '.[dbo].[Customers]' 

execute sp_executesql @t
84

utilizar una tabla temporal:

CREATE TABLE #variables 
    (
    VarName VARCHAR(20) PRIMARY KEY, 
    Value VARCHAR(255) 
    ) 
GO 

Insert into #variables Select 'Bob', 'SweetDB' 
GO 

Select Value From #variables Where VarName = 'Bob' 
GO 

DROP TABLE #variables 
go 
+10

excelente respuesta ... en realidad RESPONDIÓ la pregunta PREGUNTADA en lugar de darle una vuelta de tuerca. –

2

usted podría utilizar SQL dinámico, acaba de ser conscientes de los riesgos de seguridad con este (no 100% seguro en el Syntex correcta)

declare @bob nvarchar (50)

declare @sql nvarchar(max) 
set @bob='SweetDB' 
set @sql = 'Use ' + @bob 

execute sp_executesql @sql 
+0

Sé que esta es una respuesta antigua, pero puede aparecer en una búsqueda. Cuando la declaración se ejecuta y se devuelve el control a la rutina que realiza la llamada, seguirá utilizando la base de datos en la que estaba antes de ejecutar la declaración dinámica de "uso". Por lo tanto, esto no debe confundirse como una forma de cambiar realmente la base de datos actual. – Storm

12

prefiero la respuesta a esta pregunta this de Global Variables with GO

que tiene la ventaja añadida de ser capaz de hacer lo que originalmente quería hacer así.

La advertencia es que debe activar el modo SQLCMD (en Query-> SQLCMD) o activarlo de manera predeterminada para todas las ventanas de consulta (Herramientas-> Opciones y Resultados de consulta-> Por defecto, abra nuevas consultas en SQLCMD modo)

continuación, puede utilizar el siguiente tipo de código (completamente arrancada de que la misma respuesta por Oscar E. Fraxedas Tormo)

--Declare the variable 
:setvar MYDATABASE master 
--Use the variable 
USE $(MYDATABASE); 
SELECT * FROM [dbo].[refresh_indexes] 
GO 
--Use again after a GO 
SELECT * from $(MYDATABASE).[dbo].[refresh_indexes]; 
GO 
+0

Estaba redirigiendo salida de consulta a otro archivo (: nombre de archivo) en modo SQLCMD, y para obtener la salida vacía al archivo debe ejecutar un GO, por lo que esta: la sintaxis setvar es necesaria para reemplazar variables normales en esa situación ya que se ven obligados a dividir las cosas en lotes. – Anssssss

0

Si está utilizando SQL Server se puede configurar variables globales para los scripts enteros como:

:setvar sourceDB "lalalallalal" 

y utilizar más tarde en la escritura como:

$(sourceDB) 

Hacer el modo seguro está en SQLCMD en Servidor de Gestión Studi, puede hacerlo a través del menú superior haga clic en Consulta y cambiar el modo en SQLCMD.

Más sobre el tema se puede encontrar aquí: MS Documentation

1

tablas temporales son retenidos por las declaraciones GO, así que ...

SELECT 'value1' as variable1, 'mydatabasename' as DbName INTO #TMP 

-- get a variable from the temp table 
DECLARE @dbName VARCHAR(10) = (select top 1 #TMP.DbName from #TMP) 
EXEC ('USE ' + @dbName) 
GO 

-- get another variable from the temp table 
DECLARE @value1 VARCHAR(10) = (select top 1 #TMP.variable1 from #TMP) 

DROP TABLE #TMP 

No es bonito, pero funciona

Cuestiones relacionadas