Je configure un travail pour parcourir une liste de serveurs liés et exécuter une requête spécifique sur chacun d'eux. J'essaie d'exécuter la requête à l'intérieur d'un bloc TRY-CATCH, donc s'il y a un problème avec un serveur particulier, je peux le journaliser mais continuer avec les autres serveurs.
La requête que j'exécute à l'intérieur de la boucle ressemble à ceci:
BEGIN TRY
SELECT *
FROM OPENQUERY([server1], 'SELECT 1 AS c;');
END TRY
BEGIN CATCH
SELECT ERROR_NUMBER(), ERROR_MESSAGE();
END CATCH;
PRINT 'We got past the Catch block!';
En cas de problème de connexion au serveur, le code échoue immédiatement et n'est pas transféré vers le bloc CATCH
. Si le serveur se connecte mais qu'il y a une erreur dans la requête réelle, par ex. diviser par zéro, alors cela est capturé comme prévu par le bloc CATCH
.
Par exemple, j'ai créé un serveur lié avec un nom dont je sais qu'il n'existe pas. Lors de l'exécution de ce qui précède, je reçois simplement:
OLE DB provider "SQLNCLI" for linked server "nonserver" returned message
"Login timeout expired".
OLE DB provider "SQLNCLI" for linked server "nonserver" returned message
"An error has occurred while establishing a connection to the server.
When connecting to SQL Server 2005, this failure may be caused by the
fact that under the default settings SQL Server does not allow remote
connections.".
Msg 53, Level 16, State 1, Line 0
Named Pipes Provider: Could not open a connection to SQL Server [53].
J'ai lu BOL sur TRY-CATCH
et sachez qu'il n'attrapera pas les erreurs de niveau 20+ qui interrompent la connexion mais cela ne semble pas être le cas (ce n'est que le niveau 16).
Est-ce que quelqu'un sait pourquoi ces erreurs ne sont pas détectées correctement?
Vous pouvez essayer d'utiliser sp_testlinkedserver
. Vous pouvez également émettre le OPENQUERY
à l'aide de SQL dynamique (comme Max l'a correctement souligné), pour différer l'analyseur validant le nom du serveur jusqu'à l'exécution.
BEGIN TRY
EXEC sp_testlinkedserver N'server1';
EXEC sp_executesql N'SELECT * FROM OPENQUERY([server1],
''SELECT 1 AS c;'');';
END TRY
BEGIN CATCH
SELECT ERROR_NUMBER(), ERROR_MESSAGE();
END CATCH;
PRINT 'We got past the Catch block!';
Bien que cela fonctionne aussi bien sans sp_testlinkedserver
, cette procédure peut toujours être utile pour vous empêcher d'essayer tout un tas de code sur ce serveur ...
De plus, puisque si sp_testlinkedserver
échoue, il échoue réellement au moment de la compilation, vous pouvez différer cela et toujours le capturer en utilisant du SQL dynamique là aussi:
BEGIN TRY
EXEC master.sys.sp_executesql N'EXEC sp_testlinkedserver N''server1'';';
...
END TRY
Avez-vous essayé quelque chose comme ça?
BEGIN TRY
DECLARE @cmd nvarchar(max);
SET @cmd = 'SELECT * FROM OPENQUERY([server1], ''SELECT 1 AS c;'');';
EXEC sp_executesql @cmd;
END TRY
BEGIN CATCH
SELECT ERROR_NUMBER(), ERROR_MESSAGE();
END CATCH;
Selon les commentaires ci-dessous, cela fonctionne car l'erreur n'est plus générée au moment de la compilation. L'erreur se produit maintenant au moment de l'exécution, à l'intérieur de la procédure stockée sp_executesql.
Après enquête, il semble que cette erreur ne soit pas détectée car il s'agit d'une erreur compilation plutôt que d'une erreur d'exécution. Pour illustrer cela, essayez ce qui suit:
PRINT 'Before TRY';
BEGIN TRY
SELECT 1/0;
SELECT *
FROM OPENQUERY([nonserver], 'SELECT 1 AS c;');
END TRY
BEGIN CATCH
SELECT ERROR_NUMBER(), ERROR_MESSAGE();
END CATCH;
L'instruction initiale PRINT
n'obtient pas de sortie, pas plus que l'erreur de division par zéro n'est exécutée/interceptée. Le serveur inexistant provoque l'échec immédiat du script.
J'ai récemment eu un problème similaire où j'ai appelé une procédure distante à partir d'un TRY-CATCH et la procédure a échoué en raison de la tentative d'insertion d'une clé en double (erreur d'exécution de niveau 16). Le bloc CATCH n'a pas été appelé. J'ai trouvé la raison dans cet article: https://technet.Microsoft.com/en-us/library/ms191515 (v = sql.105) .aspx
La solution consiste à SET XACT_ABORT ON dans la procédure d'appel avant d'appeler la procédure distante. Lorsque XACT_ABORT est sur le bloc CATCH est appelé comme prévu. Vous devez savoir que le paramètre XACT_ABORT est propagé à la procédure distante, ce qui peut affecter son comportement.
ALTER PROCEDURE dbo.LinkedServer_Status
@linked_server nvarchar(128),
@exists bit OUT,
@connected bit OUT,
@server_datetime datetime OUT
AS
BEGIN
SET NOCOUNT ON;
DECLARE @server_id int;
SELECT @server_id = server_id from sys.servers where name = @linked_server;
IF (@@ROWCOUNT = 0)
SELECT @exists = 0, @connected = 0, @server_datetime = null;
ELSE BEGIN
SELECT @exists = 1;
BEGIN TRY
DECLARE @TBL TABLE(server_datetime DateTime);
DECLARE @SQL nVarChar(2048); -- MUST BE nVarChar
SELECT @SQL =
'SELECT server_datetime FROM OPENQUERY(['+RTRIM(@linked_server)+'], ''SELECT GETDATE() server_datetime'')';
INSERT @TBL EXEC sp_executesql @SQL;
SELECT TOP 1 @connected = 1, @server_datetime = server_datetime FROM @TBL;
END TRY
BEGIN CATCH
SELECT @connected = 0, @server_datetime = null;
SELECT ERROR_MESSAGE();
END CATCH
END;
END
-- now use stored procedure
SET NOCOUNT ON;
DECLARE
@linked_server nvarchar(128),
@exists bit,
@connected bit,
@server_datetime datetime
SELECT @linked_server = 'FRICKE BMS';
exec dbo.LinkedServer_Status
@linked_server,
@exists OUT,
@connected OUT,
@server_datetime OUT;
IF (@exists = 0)
PRINT 'Linked Server "' + @linked_server + '" DOES NOT Exist';
ELSE BEGIN
PRINT 'Linked Server "' + @linked_server + '" Exists';
IF (@connected = 0)
PRINT 'Linked Server "' + @linked_server + '" NOT Connected';
ELSE
PRINT 'Linked Server "' + @linked_server + '" IS Connected; Server DateTime: '+convert(varchar(25), @server_datetime, 120)
END;