Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Message d'information retourné par l'engin SQL lors du backup

11 réponses
Avatar
Karine
Bonjour,
J'ai créé une stored procedure qui me permet de lancer un backup d'une base
de données X (SQL 2005 Express).

Extrait de ma stored procedure:
...
SET @SQL = N'BACKUP DATABASE [' + @DatabaseName + '] TO DISK = ''' +
@BackupFileName + ''''
BEGIN TRY
EXEC(@SQL)
END TRY
BEGIN CATCH
-- Erreur durant le backup
SELECT @ErrorMsg = ErrorMessage, @ErrNo = ErrorNumber FROM
dbo.fnPrintError()
SET @Output = 'Full backup of database ' + @DatabaseName + ' failed with
error : ' + CHAR(10) + @ErrorMsg
PRINT @Output
END CATCH
...

Le backup fonctionne bien, toutefois, j'ai le message suivant qui est
retourné suite à l'exécution de la commande BACKUP DATABASE :

Processed 584 pages for database 'ServoxTE', file 'ServoxTE_Data' on file 7.
Processed 1 pages for database 'ServoxTE', file 'ServoxTE_Log' on file 7.
BACKUP DATABASE successfully processed 585 pages in 1.121 seconds (4.275
MB/sec).

J'ai donc 2 questions:
1) Existe-t-il un moyen de ne pas afficher ce message d'information puisque
de toute façon, je gère les erreurs dans sa stored procedure?
2) Encore mieux, existe-t-il un moyen de mettre ce message d'information
dans une variable? Dans mon exemple ci-dessus, la variable @Output contient
la description de l'erreur en cas d'erreur (géré par ma fonction
fnPrintError). J'aimerais qu'elle contienne le message d'information
retourné par l'engin SQL si le backup a bien fonctionné.

Merci de votre aide

1 réponse

1 2
Avatar
Karine
Bonjour,

Je m'explique.
J'ai une procédure spArchivage qui appelle plusieurs autres stored
procedures.
La procédure spArchivage appelle d'abord la procédure A.
Si A est exécuté avec succès, spArchivage appelle alors B.
Si B est exécuté avec succès, spArchivage appelle C, etc...
Suite à l'appel de chaque stored procedure, je log le détail dans une table
"LogArchivage".
Ce que je veux, c'est que la procédure spArchivage soit au courant des
messages d'informations retournées par l'engin SQL lors de l'appel de A, B,
C, etc, pour les ajouter dans la table "LogArchivage".

La procédure spArchivage est lancée automatiquement par une tâche cédulée
dans windows :
SQLCMD.EXE -S
.SQLExpress -i"D:ProjetsArchivageScriptsspArchivageTE.sql"

Le fichier spArchivageTE.sql lance la stored procedure spArchivage avec
certains paramètres (bd à archiver, dates, etc).

Je n'ai pas d'application qui s'occupe d'appeler la stored procedure.
Mais si je comprends bien ce que vous dites, en me crééant une application
qui fait ce que spArchivage fait, appel de chaque stored procedure, je
serais capable de capturer les messages d'information...
Mais c'est quand même bizarre qu'on ne puisse pas capturer directement ces
messages dans des variables...

Merci de votre aide.
:-)
Karine

"Med Bouchenafa" wrote in message
news:
Je ne sais pas ce que tu entends par "une tâche schedulée dans Windows"
Quoi qu'il en soit, le TRY CATCH ne peut pas "pièger" les messages
d'informations. Il ne piège que les messages dont la severité est
superieur a
10
Avec un petit script en VBScript et ADO par exemple, tu devrai facilement
pièger tous les messages dans la collection Errors d'ADO
--
Bien Cordialement
Med Bouchenafa


"Karine" wrote:

Bonjour,
La partie cliente en question est une stored procedure qui sera lancée
par
une tâche cédulée dans Windows.
La stored procedure en question appelle une dizaine d'autres stored
procedures, dans un ordre bien précis.
J'aimerais pouvoir inscrire dans une table SQL, ce qui est retournée lors
de
l'exécution de chacune des commandes.
C'est pour cette raison que je voulais capturer le message d'information
dans une variable.
J'aimerais mieux pouvoir capturer l'information, et non pas l'ignorer.
Merci de votre aide

"Med Bouchenafa" wrote in message
news:
> SQL Server est fondamentalement une application Client Serveur.
> Lorsque la partie Cliente envoie une commande, du style que tu cites, à
> la
> partie Serveur, cette dernière execute la commande et répond toujours
> avec
> un
> message d'information.
> Il appartient toujours à la partie Cliente d'afficher ou pas ce message
> d'information.
> Dans ton cas, je dirais que cela dépend du Client que tu utilises pour
> exécuter cette commande.
> Conçus, avant tout, comme des outils d'administration, les outils
> Microsoft
> affichent toujours ces messages d'information.
> Si tu tu utilses ton propre client, il te sera tout à fait possible
> d'ignorer ce message
>
>
> --
> Bien Cordialement
> Med Bouchenafa
>
>
> "Karine" wrote:
>
>> Bonjour,
>> J'ai créé une stored procedure qui me permet de lancer un backup d'une
>> base
>> de données X (SQL 2005 Express).
>>
>> Extrait de ma stored procedure:
>> ....
>> SET @SQL = N'BACKUP DATABASE [' + @DatabaseName + '] TO DISK = ''' +
>> @BackupFileName + ''''
>> BEGIN TRY
>> EXEC(@SQL)
>> END TRY
>> BEGIN CATCH
>> -- Erreur durant le backup
>> SELECT @ErrorMsg = ErrorMessage, @ErrNo = ErrorNumber FROM
>> dbo.fnPrintError()
>> SET @Output = 'Full backup of database ' + @DatabaseName + '
>> failed
>> with
>> error : ' + CHAR(10) + @ErrorMsg
>> PRINT @Output
>> END CATCH
>> ....
>>
>> Le backup fonctionne bien, toutefois, j'ai le message suivant qui est
>> retourné suite à l'exécution de la commande BACKUP DATABASE :
>>
>> Processed 584 pages for database 'ServoxTE', file 'ServoxTE_Data' on
>> file
>> 7.
>> Processed 1 pages for database 'ServoxTE', file 'ServoxTE_Log' on file
>> 7.
>> BACKUP DATABASE successfully processed 585 pages in 1.121 seconds
>> (4.275
>> MB/sec).
>>
>> J'ai donc 2 questions:
>> 1) Existe-t-il un moyen de ne pas afficher ce message d'information
>> puisque
>> de toute façon, je gère les erreurs dans sa stored procedure?
>> 2) Encore mieux, existe-t-il un moyen de mettre ce message
>> d'information
>> dans une variable? Dans mon exemple ci-dessus, la variable @Output
>> contient
>> la description de l'erreur en cas d'erreur (géré par ma fonction
>> fnPrintError). J'aimerais qu'elle contienne le message d'information
>> retourné par l'engin SQL si le backup a bien fonctionné.
>>
>> Merci de votre aide
>>
>>
>>







1 2