Discussion :

[ninouchfis]

Bonjour,

Je gère une base de donnée utilisée par une centaine d'opérateurs via des applicatifs access codés en vba.
Chaque applicatif fait appel a un fichier contenant des fonctions communes.

Quand j'ai besoin de faire des modifications dans ce fichier je dois forcer la déconnexion de tous les utilisateurs. Je fais ceci via une commande vba qui est contenu dans chaque applicatif et qui reboucle régulièrement sur une variable contenu dans une table. Quand cette variable est false, l'applicatif reste ouvert, quand elle est true l'applicatif se ferme.
Cependant quand un utilisateur vérouille sa session windows tout en laissant l'applicatif ouvert, la macro de déconnection ne fonctionne plus!

Y a t'il un moyen via sql server de forcer la déconnection de tous les utilisateurs ou d'un utilisateur spécifique? Faut il avoir des droits particuliers?

Merci d'avance

[mikedavem]

Bonjour,

Tu peux toujours supprimer tes sessions "inactives" avec la commande KILL mais cela ne reste pas très propre. Après il faut également déterminer si une session peut être supprimée ou non ...

On a déjà eu ce genre de problème avec Access et on avait mis en place une tâche planifiée dans Windows qui permettait de forcer la fermeture des formulaires Access la nuit. En effet certains utilisateurs ne se déconnectaient pas le soir et verrouillaient certaines tables durant la nuit.

A voir si cela colle avec ton contexte.

++

[ninouchfis]

Alors je n'y connais pas grand chose en tâches planifiées mais comme le nom l'indique il faut j'imagine définir une périocité d'exécution.
Dans mon cas, le besoin de forcer la fermeture des sessions access n'est pas du tout planifié. Ca peut être n'importe quand dans la journée.

[Jean-Philippe André]

salut,

pour les connections en cours, dans le tuto de fadace, on avait ce script :

Code :

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

1
2
3
4
5
6
7
8
9
10
USE master
GO
SELECT 'kill', spid
FROM sysprocesses
WHERE dbid = db_id('MaBase')
GO
/*Exécution de l'output de la commande ci-dessus afin de libérer la base */
GO
 
--RESTORE DATABASE MaBase FROM DISK=N'D:\BACKUP\MaBase.bal'

[ninouchfis]

Je ne dois pas être doué car je n'arrive pas à faire fonctionner ton code.
J'écris donc ce script:

USE master
GO
SELECT 'kill', spid
FROM sysprocesses
WHERE dbid = db_id('Hybrides')
GO

ça me retourne tout un tableau avec plusieurs lignes seulement ça ne déconnecte personne de la base...

PS: je ne suis que process_admin sur le serveur et db_owner sur la base Hybrides

[zinzineti]

--> Quelles sont les sessions/applications/utilisateurs connectés ?

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
 
SELECT
c.session_id [session_id],
c.net_transport [protocol],
c.auth_scheme [authentification],
s.login_time,
c.last_read ,
c.last_write,
s.hostname [client],
s.loginame,
@@SERVERNAME AS [server],
s.program_name,
s.status
FROM sys.dm_exec_connections c INNER JOIN sys.sysprocesses s ON c.session_id = s.spid
WHERE session_id <> @@SPID

--> Comment Killer les sessions/applications/utilisateurs connectés ?
il faut utiliser le numéro de la (les) session_id listés ci-dessus et faire ensuite

Code :

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

KILL session_id

[Ptit_Dje]

Vous pouvez exécuter ceci:

Code :

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

ALTER DATABASE [Nom de db] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

Après votre maintenance:

Code :

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

ALTER DATABASE [Nom de db] SET MULTI_USER;

[mikedavem]

Ce qui me gène dans la méthode est de forcer la déconnexion depuis SQL Server à tout moment.

Que se passe-t-il si une personne est en train de travailler à ce moment là ? On arrête son travail ? Il est probable qu'il n'y ait pas le choix mais quand même ...

Chaque applicatif fait appel a un fichier contenant des fonctions communes.

On parle de fichier ou de bases de données ? Juste pour être certain ...

++

[Ptit_Dje]

Je suppose que les utilisateurs sont avertis à l'avance par email de la fenetre de maintenance.
Qu'une procédure "d'arrêt de leur travail" (ou comment ne pas perdre de données... tout fermer et tout cela) leur a été communiquer.
Que la maintenance a été approuvée.
Bref, il y a un travail à faire en amont sinon c'est clair que c'est barbare et pas très propre.

Après, s'il faut commencer a attendre que le gars qui est parti en vacances 3 semaines et qui a locké sa session windows revienne pour qu'il ferme sa session proprement et ainsi de suite, on est pas prêt d'avancer.

[ninouchfis]

En fait les applicatifs sont des projets access (.adp) qui ont tous une référence commune qui est un autre projet acces (.ade)
A chaque fois que je dois réaliser une maintenance sur le fichier ade je dois faire en sorte que personne ne l'utilise.
Un message s'affiche alors a tous les utilisateurs en les prévenant qu'une opération des maintenance est en cours. A partir de la ils ont 5 minutes pour finir ce qu'ils ont à faire et après leur applicatif se fermera automatiquement.
En parallèle personne ne peut ouvrir d'applicatifs.
Seulement les personnes qui laisse un appli ouvert avec leur session windows verrouillée, empêche la fermeture automatique d'access.
Donc rien de trop violent, les utilisateurs sont bien avertis.

Les solutions de déconnexion de zinzineti et Ptit_Dje fonctionnent très bien, dans le sens ou les utilisateurs sont bien déconnectés mais les applicatifs restent ouverts et ont toujours pour référence le fichier commun.
Donc en fait déconnecter les users de la base ne résoud malheureusement pas mon problème. Ils faudrait en fait forcer la fermeture d'access sur leur pc et la je crois que ça devient très compliqué...

Une petite idée peut être?

[Ptit_Dje]

Méthode barbare, regarder et fermer les handles sur le fichier en utilisant process explorer.

[ninouchfis]

Alors je n'ai pas les droits administrateur sur mon pc donc je ne peux rien installer dessus.
En fouillant un peu j'ai l'impression qu'on pourrait éventuellement réaliser cette opération en vba.
Je sort par contre un peu du thème SQL-server, je devrais peut être me rediriger vers un autre groupe de discussion...