Discussion :

[Sytchev3]

Comment peut-on déconnecter tous les utilisateurs d'une base de données ???

Je sais que dans
-> Gestion
-> Activité en cours
-> informations sur le processus si l'on choisit un utilisateur (click droit) et terminer le processus on "deconnecte de la base" l'utilsateur choisi

Mais existe il un autre moyen une instruction SQL ou autre

Je vous remercie d'avance pour votre aide

[Fabien Celaia]

Exécuter l'output de la commande suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
select "KILL ", spid 
from master..sysprocesses 
where dbid=db_id('Votre Base')

[Sytchev3]

Merci pour le code, mais est-ce normal que le KILL soit entre " " ?

Car lorsque j'exécute la requête il y a une erreur à ce niveau.

Merci d'avance

[WOLO Laurent]

Il voulait dire ceci:

Exécuter l'output de la commande suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
select 'KILL ', spid 
from master..sysprocesses 
where dbid=db_id('Votre Base')

[Sytchev3]

L'instruction n'a pas l'air de fonctionner j'ai beau actualiser entreprise manager ou le quitter les spid sont encore présents.

[SQLpro]

Mieux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ALTER DATABASE <mabase>
SET SINGLE_USER WITH ROLLBACK IMMEDIATE

A +

[Sytchev3]

Encore mieux j'ai trouvé une procédure stockée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
CREATE PROC killuser 
AS 
 
BEGIN
 
 
Declare @T nvarchar(10) 
declare Decon CURSOR FOR 
   select convert(varchar(4), spid) 
   from master..sysprocesses 
   where dbid = db_id('BASETEST') 
   and spid <> @@spid 
 
Declare @spid as varchar(4); 
OPEN Decon 
FETCH NEXT FROM Decon 
   into  @spid; 
WHILE (@@FETCH_STATUS = 0) 
begin 
set @T = 'KILL '+ @spid 
exec sp_executesql @T 
FETCH NEXT FROM Decon 
  into  @spid; 
end 
CLOSE Decon 
DEALLOCATE Decon; 
END 
GO

[Merci d'utiliser les balises codes]Modéré par WOLO Laurent

[Sytchev3]

SQLpro Ton instruction SQL ne me permet d'avoir qu'un seul utilisateur connecté à la base et ce n'est pas ce que je veux.

Comment puis je faire pour revenir en arrière maintenant ???

[WOLO Laurent]

Quel arrière ?

[SQLpro]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ALTER DATABASE <mabase>
SET MULTI_USER

Votre scrip est particulièrement dangereux :
1) il tue des connexions sans se soucier des transactions en cours. C'est donc un excellent moyen de pourrir une base de données jusqu'à la rendre inutilisable
2) ce script ne garantie nuellement pendant son exécution que de nouvelles connexions se fassent.

Vous feriez mieux de suivre un cours d'administration SQL Server avant de vous lancer dans de telles procédures...

A +

[Sytchev3]

En fait les utilisateurs devront être prévenus qu'ils doivent arrêter de travailler sur la base de données

Mais comme toujours il existe quelques irréductibles qui continue à être sur la base on les kill comme ça il n'y a pas de problèmes.

Cependant il est vrai que mon script ne garantie pas que d'autres connexions se fassent.

En utilisant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ALTER DATABASE <mabase> 
SET MULTI_USER

Il n'y a qu'un seul utilisateur possible et il s'agit du superadministrateur ou du propriétaire de la base je suppose

[SQLpro]

En fait les utilisateurs devront être prévenus qu'ils doivent arrêter de travailler sur la base de données

Si vous bâtissez votre logique procédurale sur des éléments aussi instable, je ne donna pas cher de votre avenir professionnel !!!

Il n'y a qu'un seul utilisateur possible et il s'agit du superadministrateur ou du propriétaire de la base je suppose

Il s'agit de vous puisque c'est vous qui exécutez la commande. Donc minimum db_owner voire sysadmin !!!!!


A +

[Sytchev3]

Si vous bâtissez votre logique procédurale sur des éléments aussi instable, je ne donna pas cher de votre avenir professionnel !!!

Comment peut - on s'assurer qu'aucun utilisateur ne soit connecté à la base à un instant T ormis avec votre solution. Le fait qu'il n'y est pas d'utilsateurs connectés est forcément instable puisqu'il y en a toujours qui n'écoute pas ce qu'on leur dit. Pour mon avenir professionel mon supérieur (chef de projet) m'a demandé de réaliser cette action, j'execute.

[Fabien Celaia]

Votre scrip est particulièrement dangereux :
1) il tue des connexions sans se soucier des transactions en cours. C'est donc un excellent moyen de pourrir une base de données jusqu'à la rendre inutilisable

Non : le kill via T-SQL nettoie proprement les connexions tuées (rollback) ou ne les tue pas.