Cet élément est en cours d'utilisation. :(

Version imprimable

Bonjour à tous :P

Tout d'abord, merci pour tout ce que j'ai appris grâce à ce forum depuis des années.

Si je prend la plume virtuelle c’est que je n’ai pas réussi à trouver mon bonheur cette fois.

Je cherche à identifier les logins windows qui me bloque l’accès à certaines tables.

Par exemple à la table F_DOCENTETE.

Je sais identifier la liste des documents ouverts grâce à cette fonction :
Code:

1 2 3 4 5 6 7 8 9 DECLARE @lBase int, @lTable int, @lRes int SELECT @lBase = DB_ID() SELECT @lTable = OBJECT_ID(@cbFile) EXECUTE master..xp_CBIsRecordLock @@SPID,@lBase,@lTable,@cbMarq,@lRes OUTPUT RETURN @lRes
Je peux savoir qui se cache derrière un processus, mais il faut que je connaisse son ID.
Je pourrais me servir d'une requête dans ce genre-là.

Code:

SELECT NT_USERNAME,* FROM MASTER..SYSPROCESSES WHERE spid = @@SPID

Bref, je sais quels documents sont bloqués.
Je sais comment identifier si j’ai l’ID, mais je ne sais pas identifier qui bloque quoi ou qui est sur quoi.

Une idée ? :P

Précision d'importance, il faut que cela fonctionne sous SQL2000.

05/10/2009, 19h20
elsuket

bonjour,

Sous SQL Server 2000, la seule solution me semble de requêter la table master.dbo.sysprocesses.

Sous SQL Server 2005 et 2008, vous pouvez utilisez les vues et fonctions de gestion dynamiques :
- sys.dm_exec_sessions
- sys.dm_exec_connections
- sys.dm_exec_requests
- sys.dm_exec_sql_text

Pour savoir quelle tâche en bloque d'autres, et extraire l'instruction en cours d'exécution qui provoque le bloquage ;)

@++ ;)
06/10/2009, 10h05
Blade68

Bonjour,

Merci de votre réponse déjà. :P

Je n'ai que SQL2000 à disposition, donc je ne peux utiliser que master.dbo.sysprocesses

J'ai regardé, on ne voit pas quelle table est en cours d'utilisation.

J'ai l'impression que je ne suis pas en face d'un vrai blocage, mais plutôt
d'un système de flag qui verrouille la ligne sans utiliser les blocages SQL.

La colonne "blocked" est à 0 partout dans master.dbo.sysprocesses.

Je cherche comment savoir qui utilise quoi et je ne vois pas. :cry:
06/10/2009, 14h08
Ptit_Dje

Est ce que sp_lock repond a votre attente ?

http://msdn.microsoft.com/en-us/libr...4(SQL.80).aspx
06/10/2009, 14h16
Blade68

Non, malheureusement.

Ni

Code:

EXECUTE sp_who

ou

Code:

EXECUTE sp_who2

Merci quand même.

Je soupçonne qu'il y ai une information mémorisée quelque part
dans une table spécifique, mais je ne sais pas où.

Cette base, est une base Sage.
Elle utilise des verrous qui ne sont pas des blocages SQL. :?

Ce n'est pas gagné mon histoire.

Bref, je craint que je n'aurais pas de réponses vu que les verrous
sont spécifiques.
06/10/2009, 14h40
SQLpro

je pense que vous confondez verrous et privilèges d'exécution.

Un privilège est la possibilité pour un utilisateur d'accéder à telle ou telle table ou vue pour une commande SQL précise (SELECT, UPDATE, INSERT, DELETE). Lisez ce que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/sqlaz/dcl/

Un verrou est un mécanisme interne au moteur destiné à protéger l'accès à la ressource (ligne, page, table....) le temps d'une lecture ou d'une mise à jour.

Sous SAGE les tables sont protégées de la mise à jour par des mécanismes de CHECKSUM spécifique afin des les bidouilleurs n'aillent pas foutre la m... en polluant les données. Ceci pour des questions de responsabilité juridiques parfaitement justifiées.

A +
07/10/2009, 10h26
Blade68

Bonjour et merci de votre réponse.

Non, je ne confond pas.

Mon besoin est assez simple.

Quand un utilisateur est sur un document précis, aucun autre ne
peut y accéder.

Même pas pour le lire...

Mon but est d'arriver à identifier qui est l'utilisateur qui bloque le document
afin de lui demander de sortir au plus vite.

Là, en l'état, dans une entreprise, il faut téléphoner à tous les utilisateurs
de Sage pour savoir qui est sur le document qu'on veut ouvrir.

Dès que le "bloqueur" ferme son document, on peut y accéder.
Mais il faut savoir qui c'est.
Il n'est pas question de faire des bidouilles, mais simplement de faire une liste. :P

Je ne pense pas que ce soit les privilèges dans ce cas.
Car dès que le document est fermé, on y a accès.

J'ai mis un traceur dans la base et je n'ai trouvé que des appels à des DLL
spécifique à Sage, donc pas d'info après cela.
07/10/2009, 11h07
mikedavem

Citation:

Envoyé par SQLpro

Sous SAGE les tables sont protégées de la mise à jour par des mécanismes de CHECKSUM spécifique afin des les bidouilleurs n'aillent pas foutre la m...
A +

Je ne vois vraiment pas la suite :mouarf:

Bref redevenons sérieux. Comme vous le dites vous n'êtes pas dans un cas de verrou posé par le moteur SQL. J'ai eu l'occasion de travailler avec un logiciel qui faisait exactement ce que vous voulez. Pour pouvoir faire cela, l'information était trappée dans la base avec l'ID du document, l'ID et le nom de l'utilisateur.

Dans votre cas il serait bon d'ajouter cette information en rajoutant une colonne par exemple à votre table ...

++

La procédure qui met le lock Sage est ci-dessous.

On voit que l'ID utilisateur est utilisé effectivement.
Ainsi que le nom de la base et de la table.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE PROCEDURE [dbo].[CB_LockRecord] @cbFile sysname, @cbType smallint, @cbMarq int AS 
BEGIN
	DECLARE 
		@lBase int,
		@lTable int,
		@lRes int
 
	SET NOCOUNT ON
	SELECT @lBase = DB_ID()
	SELECT @lTable = OBJECT_ID(@cbFile)
	EXECUTE @lRes = master..xp_CBLockRecord @@SPID,@lBase,@lTable,@cbType,@cbMarq
	IF @lRes <> 0
	BEGIN
		RAISERROR(@lRes,11,1) WITH SETERROR
		RETURN
	END
END

Je continue mes recherches. :P

07/10/2009, 17h33
SQLpro

xp_CBLockRecord est une procédure étendue codée en C++ et probablement éditée par SAGE afin de protéger les éléments de la base des mauvaises intentions des utilisateurs....

A +
07/10/2009, 18h08
Blade68

J'ai appelé Sage l'éditeur (je travaille pour un revendeur)

Ils me disent que ce n'est pas eux qui ont créer xp_CBLockRecord, mais
qu'ils l'utilisent dans leurs traitements de verrous.

Ils ont une procédure dans chaque base qui appelle xp_CBLockRecord de la base master.

Ils disent qu'ils ne savent pas ou vont les données gérer par cette procédure
de la base master.

Bref, j'ai une solution.

Je peux au moment de l'appel de cette procédure ajouter un petit
traitement spécifique qui mémorise les données dans une table spécifique.

Mais je n'aime pas trop cela.

Ca équivaut à modifier une procédure stockées de l'éditeur. :?
08/10/2009, 09h18
Ptit_Dje

Vous pouvez penser a executer la procedure en tournant une trace sur votre serveur. De ce fait, vous parviendrez peut etre a voir ce qu'il se passe en coulisses.
08/10/2009, 09h30
Blade68

Bonjour,

Déjà fait.

Appel de la procédure Sage de la base en cours nommé CB_LockRecord

Procédure qui appelle elle-même xp_CBLockRecord de la base Master.

Après, aucune info...
30/09/2010, 17h45
cetipar

même pb

J'ai exactement le même pb avec une Gescom Sage 100

Mon client se retrouve d'un seul coup avec plein de commandes impossibles à ouvrir. J'ai le message "ce document est en cours d'utilisation".

Si tous les utilisateurs quittent l'appli, les commandes redeviennent "ouvrables", mais il y a 30 utilisateurs et certains sur des sites distants.

J'aimerais moi aussi savoir comment retrouver l'utilisateur qui bloque.