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

[SQL2005] WAITFOR + GOTO ?

3 réponses
Avatar
OokieDookie
Bonjour à tous,

Serveur autonome SQL2005 SP3 French_CI_AS, je suis seul utilisateur de ma
base de test.

Je voudrais utiliser WAITFOR pour afficher à intervalles réguliers le
résultat d'une requête.
J'ai consulté la doc et créé une requête toute simple (le but étant ensuite
de remplacer GETDATE par une variable VARCHAR) :

------
USE AdventureWorks

LBL1 :
PRINT GETDATE()
WAITFOR DELAY '00:00:10'
GOTO LBL1
------

-1ère chose, cela met un certain temps à démarrer (plus d'une minute).
Si j'utilise 5 minutes, rien au bon de 20 minutes...

J'ai trouvé dans la doc que "Le délai réel peut être différent du délai
spécifié dans time_to_pass, time_to_execute ou timeout, et il dépend du
volume d'activité du serveur. Le compteur démarre lorsque le thread associé à
l'instruction WAITFOR est planifié. Si le serveur est occupé, il est possible
que le thread ne soit pas immédiatement planifié ; par conséquent, le délai
peut être supérieur à la durée spécifiée."
OK mais je pensais avoir le premier résultat, patienter un peu et en avoir
ensuite à intervalles réguliers, ce qui n'est pas le cas. Je ne comprends pas
pourquoi ?


Lorsque j'exécute l'exemple de la doc suivant, il me faut 10 sec, pas une
vraie minute, pour avoir le résultat :
------
BEGIN
WAITFOR DELAY '00:00:05';
EXECUTE sp_helpdb;
END;
GO
------

L'exemple avec une variable locale (création de la PS
dbo.TimeDelay_hh_mm_ss) marche aussi en 10 secondes.

-2d point plus gênant, quand ça "part" (ou que j'annule), je récupère plus
d'une dizaines de lignes de résultat alors que je n'ai qu'une seule
instruction PRINT

Est-ce du à l'utilisation de GOTO ?

Merci pour vos remarques et explications éclairées.

Bonne fin de journée.

3 réponses

Avatar
Med Bouchenafa
PRINT utilise un buffer qui n'est envoyé au client que lorsqu'il est plein
ou que le batch est fini

Le WAITFOR DELAY n'a aucun effet sur lui

Habituellement, pour resoudre ce genre de probleme on utilise
RAISERROR ('xxxxxxxxxxxxxxx', 0, 1) WITH NOWAIT

Bien cordialement
Med Bouchenafa

"OokieDookie" wrote in message
news:
Bonjour à tous,

Serveur autonome SQL2005 SP3 French_CI_AS, je suis seul utilisateur de ma
base de test.

Je voudrais utiliser WAITFOR pour afficher à intervalles réguliers le
résultat d'une requête.
J'ai consulté la doc et créé une requête toute simple (le but étant
ensuite
de remplacer GETDATE par une variable VARCHAR) :

------
USE AdventureWorks

LBL1 :
PRINT GETDATE()
WAITFOR DELAY '00:00:10'
GOTO LBL1
------

-1ère chose, cela met un certain temps à démarrer (plus d'une minute).
Si j'utilise 5 minutes, rien au bon de 20 minutes...

J'ai trouvé dans la doc que "Le délai réel peut être différent du délai
spécifié dans time_to_pass, time_to_execute ou timeout, et il dépend du
volume d'activité du serveur. Le compteur démarre lorsque le thread
associé à
l'instruction WAITFOR est planifié. Si le serveur est occupé, il est
possible
que le thread ne soit pas immédiatement planifié ; par conséquent, le
délai
peut être supérieur à la durée spécifiée."
OK mais je pensais avoir le premier résultat, patienter un peu et en avoir
ensuite à intervalles réguliers, ce qui n'est pas le cas. Je ne comprends
pas
pourquoi ?


Lorsque j'exécute l'exemple de la doc suivant, il me faut 10 sec, pas une
vraie minute, pour avoir le résultat :
------
BEGIN
WAITFOR DELAY '00:00:05';
EXECUTE sp_helpdb;
END;
GO
------

L'exemple avec une variable locale (création de la PS
dbo.TimeDelay_hh_mm_ss) marche aussi en 10 secondes.

-2d point plus gênant, quand ça "part" (ou que j'annule), je récupère plus
d'une dizaines de lignes de résultat alors que je n'ai qu'une seule
instruction PRINT

Est-ce du à l'utilisation de GOTO ?

Merci pour vos remarques et explications éclairées.

Bonne fin de journée.



Avatar
OokieDookie
Re,

Pour le point 2 visiblement c'est que les résultats s'empilent et sont
retournés soit par paquets, soit quand j'arrête la requête.

Ce que je veux en fait, c'est pouvoir planifier sans utiliser l'agent SQL
Server pour des raisons de restrictions de sécurité.
S'il existe d'autres moyens que WAITFOR/GOTO je suis preneur.
Si possible je voudrais cependant que ça reste au niveau SSMS, mais s'il y a
une solution non intrusive (batch ?) pourquoi pas ?

Bonne journée.

"OokieDookie" wrote:

Bonjour à tous,

Serveur autonome SQL2005 SP3 French_CI_AS, je suis seul utilisateur de ma
base de test.

Je voudrais utiliser WAITFOR pour afficher à intervalles réguliers le
résultat d'une requête.
J'ai consulté la doc et créé une requête toute simple (le but étant ensuite
de remplacer GETDATE par une variable VARCHAR) :

------
USE AdventureWorks

LBL1 :
PRINT GETDATE()
WAITFOR DELAY '00:00:10'
GOTO LBL1
------

-1ère chose, cela met un certain temps à démarrer (plus d'une minute).
Si j'utilise 5 minutes, rien au bon de 20 minutes...

J'ai trouvé dans la doc que "Le délai réel peut être différent du délai
spécifié dans time_to_pass, time_to_execute ou timeout, et il dépend du
volume d'activité du serveur. Le compteur démarre lorsque le thread associé à
l'instruction WAITFOR est planifié. Si le serveur est occupé, il est possible
que le thread ne soit pas immédiatement planifié ; par conséquent, le délai
peut être supérieur à la durée spécifiée."
OK mais je pensais avoir le premier résultat, patienter un peu et en avoir
ensuite à intervalles réguliers, ce qui n'est pas le cas. Je ne comprends pas
pourquoi ?


Lorsque j'exécute l'exemple de la doc suivant, il me faut 10 sec, pas une
vraie minute, pour avoir le résultat :
------
BEGIN
WAITFOR DELAY '00:00:05';
EXECUTE sp_helpdb;
END;
GO
------

L'exemple avec une variable locale (création de la PS
dbo.TimeDelay_hh_mm_ss) marche aussi en 10 secondes.

-2d point plus gênant, quand ça "part" (ou que j'annule), je récupère plus
d'une dizaines de lignes de résultat alors que je n'ai qu'une seule
instruction PRINT

Est-ce du à l'utilisation de GOTO ?

Merci pour vos remarques et explications éclairées.

Bonne fin de journée.



Avatar
OokieDookie
Merci, ça fonctionne impec.
Bonne journée.

"Med Bouchenafa" wrote:

PRINT utilise un buffer qui n'est envoyé au client que lorsqu'il est plein
ou que le batch est fini

Le WAITFOR DELAY n'a aucun effet sur lui

Habituellement, pour resoudre ce genre de probleme on utilise
RAISERROR ('xxxxxxxxxxxxxxx', 0, 1) WITH NOWAIT

Bien cordialement
Med Bouchenafa

"OokieDookie" wrote in message
news:
> Bonjour à tous,
>
> Serveur autonome SQL2005 SP3 French_CI_AS, je suis seul utilisateur de ma
> base de test.
>
> Je voudrais utiliser WAITFOR pour afficher à intervalles réguliers le
> résultat d'une requête.
> J'ai consulté la doc et créé une requête toute simple (le but étant
> ensuite
> de remplacer GETDATE par une variable VARCHAR) :
>
> ------
> USE AdventureWorks
>
> LBL1 :
> PRINT GETDATE()
> WAITFOR DELAY '00:00:10'
> GOTO LBL1
> ------
>
> -1ère chose, cela met un certain temps à démarrer (plus d'une minute).
> Si j'utilise 5 minutes, rien au bon de 20 minutes...
>
> J'ai trouvé dans la doc que "Le délai réel peut être différent du délai
> spécifié dans time_to_pass, time_to_execute ou timeout, et il dépend du
> volume d'activité du serveur. Le compteur démarre lorsque le thread
> associé à
> l'instruction WAITFOR est planifié. Si le serveur est occupé, il est
> possible
> que le thread ne soit pas immédiatement planifié ; par conséquent, le
> délai
> peut être supérieur à la durée spécifiée."
> OK mais je pensais avoir le premier résultat, patienter un peu et en avoir
> ensuite à intervalles réguliers, ce qui n'est pas le cas. Je ne comprends
> pas
> pourquoi ?
>
>
> Lorsque j'exécute l'exemple de la doc suivant, il me faut 10 sec, pas une
> vraie minute, pour avoir le résultat :
> ------
> BEGIN
> WAITFOR DELAY '00:00:05';
> EXECUTE sp_helpdb;
> END;
> GO
> ------
>
> L'exemple avec une variable locale (création de la PS
> dbo.TimeDelay_hh_mm_ss) marche aussi en 10 secondes.
>
> -2d point plus gênant, quand ça "part" (ou que j'annule), je récupère plus
> d'une dizaines de lignes de résultat alors que je n'ai qu'une seule
> instruction PRINT
>
> Est-ce du à l'utilisation de GOTO ?
>
> Merci pour vos remarques et explications éclairées.
>
> Bonne fin de journée.
>