[WD10] Utilisation des ordres HLit.. avec l'accès natif de PC-SOFT - Gestion des blocages

Le
Emmanuel Haefele
Bonjour,

J'ai une application qui utilise HF et que je souhaiterais ouvrir à
d'autres bases tout en conservant le code existant et l'utilisation des
ordres HLit. Pour mes tests j'utilise l'accès natif sql server de pc-soft
ainsi que Sql Server Studio Express (que je connais très peu pour
l'instant).

Soit un ordre du type :
HLitRecherchePremier ( sFic, sRub, sVal, hBlocageEcriture )

D'après la doc il n'est pas possible d'utiliser les options de blocage du
type hBlocageEcriture car dans ce cadre le test de blocage ne s'effectue
qu'au moment de l'écriture, donc je cherche à simuler cette fonction de la
façon suivante :

FONCTION LitBloqueCleUnique ( sFic, sRub, sVal )
SI HLitRecherchePremier ( sFic, sRub, sVal ) ALORS
bRes = HModifie ( sFic)
SI PAS HErreurBlocage() ALORS
HBloqueNumEnr ( sFic )
RENVOYER VRAI
FIN
FIN
RENVOYER FAUX

Ma première question est de savoir si vous pensez que cette façon de
procéder est viable ou est-ce qu'il y en aurait une autre qui serait
meilleure ?

En fait je rencontre un problème dans mes tests d'où ma question. Par
exemple :

Si un poste bloque un enregistrement du fichier par cette méthode, il
arrive (mais pas systématiquement) qu'un autre poste ait des problèmes en
ajout sur un autre enregistrement totalement différent :

SI PAS HLitRecherchePremier ( sFic, sRub, sVal ) ALORS
HRAZ ( sFic )

bRes = HAJOUTE ( sFic )
FIN

Ici l'ajout ne se fait pas, bRes = Faux et HerreurBlocage = Vrai. Pourquoi
l'ajout n'est-il pas possible, on dirait que la totalité du fichier est
bloqué ?

Je dois dire que je me pose quelques questions sur ma façon de procéder et
remercie celui ou celle qui aurait une idée qui pourrait peut-être me
diriger dans une direction ou une autre ?


Amicalement,

Emmanuel Haefelé.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Firetox
Le #14616311
Bnojour, emmanuel

il faudrait savoir exactement quelle requete est envoyée dans le cas de
SQLServer
car il et possible de bloquer sur SQLServer au niveau de la lecture a la
ligne :

il faut rajouter a la requete : WITH(UPDLOCK, HOLDLOCK, ROWLOCK)
ex select * from produit WITH(UPDLOCK, HOLDLOCK, ROWLOCK) where produit_ID
= 'AAABBB'

avec cette option dans le select tous les autres select avec ce code
renverrons faux, sinon effectivement tu auras le fait que c'est bloqué au
niveau de l'update (ou ecriture)
dans ce cas c'est : WITH(HOLDLOCK, ROWLOCK) qui est envoyé.

je pense que l'acces natif de l'editeur envoi cela : d'ou le bloquage
uniquement au niveau de l'ecriture.

donc comme on ne sait pas ce qui est envoyé dans l'acces natif, mais vu le
resultat, je pense que c'est le cas 2. et donc a moins de changer dans
l'acces tu ne pourras pas avoir le lock sur le select.

de plus visiblement le lock est fait egalement sur la table complete dans ce
cas, sinon tu n'aurais pas le message comme quoi une autre ligne est bloque
et t'empeche de bloquer la ligne qui est differentes.

bref tout ca pour dire , que si tu peux avoir les log sur ton serveur tu
pourras voir les requetes qui sont envoyé et voir ce qui se passe. je vais
voir si on peut comme sous mySQL voir toutes les requetes qui arrivent au
serveur , et tu pourras nous dire qu'elle requetes sont envoyées par l'acces
natif

Bon dev
@+




"Emmanuel Haefele" 46c41914$0$25945$
Bonjour,

J'ai une application qui utilise HF et que je souhaiterais ouvrir à
d'autres bases tout en conservant le code existant et l'utilisation des
ordres HLit. Pour mes tests j'utilise l'accès natif sql server de pc-soft
ainsi que Sql Server Studio Express (que je connais très peu pour
l'instant).

Soit un ordre du type :
HLitRecherchePremier ( sFic, sRub, sVal, hBlocageEcriture )

D'après la doc il n'est pas possible d'utiliser les options de blocage du
type hBlocageEcriture car dans ce cadre le test de blocage ne s'effectue
qu'au moment de l'écriture, donc je cherche à simuler cette fonction de la
façon suivante :

FONCTION LitBloqueCleUnique ( sFic, sRub, sVal )
SI HLitRecherchePremier ( sFic, sRub, sVal ) ALORS
bRes = HModifie ( sFic)
SI PAS HErreurBlocage() ALORS
HBloqueNumEnr ( sFic )
RENVOYER VRAI
FIN
FIN
RENVOYER FAUX

Ma première question est de savoir si vous pensez que cette façon de
procéder est viable ou est-ce qu'il y en aurait une autre qui serait
meilleure ?

En fait je rencontre un problème dans mes tests d'où ma question. Par
exemple :

Si un poste bloque un enregistrement du fichier par cette méthode, il
arrive (mais pas systématiquement) qu'un autre poste ait des problèmes en
ajout sur un autre enregistrement totalement différent :

SI PAS HLitRecherchePremier ( sFic, sRub, sVal ) ALORS
HRAZ ( sFic )
...
bRes = HAJOUTE ( sFic )
FIN

Ici l'ajout ne se fait pas, bRes = Faux et HerreurBlocage = Vrai. Pourquoi
l'ajout n'est-il pas possible, on dirait que la totalité du fichier est
bloqué ?

Je dois dire que je me pose quelques questions sur ma façon de procéder et
remercie celui ou celle qui aurait une idée qui pourrait peut-être me
diriger dans une direction ou une autre ?


Amicalement,

Emmanuel Haefelé.



Emmanuel Haefele
Le #14616301
"Firetox"
Bonjour Firetox,

il faudrait savoir exactement quelle requete est envoyée dans le cas de
SQLServer



Voici ce que l'accès natif fait exactement pour ma procédure de blocage :

SI HLitRecherchePremier ( sFic, sRub, sVal ) ALORS



est traduit par :
SELECT [INI],[DATE],[HEURE] FROM [SESSIONS] (NOLOCK) WHERE [INI] LIKE 'NJ'
ORDER BY [INI]

bRes = HModifie ( sFic)



est traduit par :
UPDATE [SESSIONS] SET [INI]='NJ',[DATE]=CONVERT(DATETIME,
'20070816'),[HEURE]=CONVERT(DATETIME, '19000101 12:09') WHERE [INI] LIKE
'NJ'

HBloqueNumEnr ( sFic )



est traduit par :
SELECT * FROM [SESSIONS] (HOLDLOCK) WHERE [INI] LIKE 'NJ'

Peux-tu me dire ce que tu en penses ?


Amicalement,

Emmanuel Haefelé.
Firetox
Le #14616291
est traduit par :
SELECT * FROM [SESSIONS] (HOLDLOCK) WHERE [INI] LIKE 'NJ'

c'est bien un lock a l'ecriture seul l'update renverra que la ligne est
bloquée
pas les autres select car HoldLock signifie : maintient du verrou jusqu'à la
fin de la transaction
donc qu'il y ai update ou non le verrour est maintenu jusqu'a la fin de la
transaction

UPLOCK pose un verrou de mise à jour au lieu d'un verrou partagé. c'est
comme ca que le select est bloque
alors qu'un verrour partagé ne bloquera que l'update.

le hlitPremier lui ne verouille rien,


maintenant reste a savoir pourqoui ton deuxieme enreg est bloque.
je pense que cela est du au transaction, mais faudrait avoir les begin et
commit dans la sequence des requete
ca tu peux le voir uniquement avec les log quoi que ...







"Emmanuel Haefele" 46c42547$0$25948$
"Firetox"
Bonjour Firetox,

il faudrait savoir exactement quelle requete est envoyée dans le cas de
SQLServer



Voici ce que l'accès natif fait exactement pour ma procédure de blocage :

SI HLitRecherchePremier ( sFic, sRub, sVal ) ALORS



est traduit par :
SELECT [INI],[DATE],[HEURE] FROM [SESSIONS] (NOLOCK) WHERE [INI] LIKE 'NJ'
ORDER BY [INI]

bRes = HModifie ( sFic)



est traduit par :
UPDATE [SESSIONS] SET [INI]='NJ',[DATE]=CONVERT(DATETIME,
'20070816'),[HEURE]=CONVERT(DATETIME, '19000101 12:09') WHERE [INI] LIKE
'NJ'

HBloqueNumEnr ( sFic )



est traduit par :
SELECT * FROM [SESSIONS] (HOLDLOCK) WHERE [INI] LIKE 'NJ'

Peux-tu me dire ce que tu en penses ?


Amicalement,

Emmanuel Haefelé.



Emmanuel Haefele
Le #14616281
"Firetox" news:46c42801$0$412$

maintenant reste a savoir pourqoui ton deuxieme enreg est bloque.
je pense que cela est du au transaction, mais faudrait avoir les begin
et commit dans la sequence des requete



Je te remercie, à priori les logs ne sont pas actif par défaut je vais
voir comment les activer. Ceci dit est-ce que tu penses que ma simulation
de blocage en lecture (HlitRecherchePremier, HModifie puis hBloqueNumEnr)
te parait correct sur le principe ou tu ferais ça d'une façon différente ?


Amicalement,

Emmanuel Haefelé.
Firetox
Le #14616271
c'est un peu lourd comme method emais c'est la seule que tu puisse mettre en
place
car il te faut un update pour voir que l'enreg est bloqué.

par contre comme le parametre ROWLOCK n'est pas précise SQLServer va poser
des verrous de page ou de table c'est pour ca que parfois tu bloque toutes
la table ou si ton deuxieme poste essaye de locker un enreg dans la meme
page il sera obligé d'attendre. c'est pour cela que parfois ton deuxieme
poste se bloque sur l'update. avec le ROWLOCK ce cas ne se produit pas. Par
contre effectivement ce n'est pas systhematique. parfois ca passe j'ai
essayé un bon nombre de fois

mais dans l'etat des choses tu est obligé de faire un hmodifie pour savoir
si la ligne est lockée sur un autre poste

@+


"Emmanuel Haefele" 46c42b80$0$5079$
"Firetox" news:46c42801$0$412$

maintenant reste a savoir pourqoui ton deuxieme enreg est bloque.
je pense que cela est du au transaction, mais faudrait avoir les begin
et commit dans la sequence des requete



Je te remercie, à priori les logs ne sont pas actif par défaut je vais
voir comment les activer. Ceci dit est-ce que tu penses que ma simulation
de blocage en lecture (HlitRecherchePremier, HModifie puis hBloqueNumEnr)
te parait correct sur le principe ou tu ferais ça d'une façon différente ?


Amicalement,

Emmanuel Haefelé.



Emmanuel Haefele
Le #14616251
"Firetox"
par contre comme le parametre ROWLOCK n'est pas précise SQLServer va
poser des verrous de page ou de table c'est pour ca que parfois tu
bloque toutes la table ou si ton deuxieme poste essaye de locker un


enreg
dans la meme page il sera obligé d'attendre.



Là tu m'interpelles à nouveau car ce verrou je le pose au lancement de mon
appli et le retire à sa fermeture. D'après ce que tu me dis, mon
utilisateur risque d'attendre longtemps avant d'accèder à l'appli :-(

Est-ce que ça veut dire que je vais être obligé d'abandonner ce principe
et qu'il n'est pas exploitable avec en SQL ?


Amicalement,

Emmanuel Hafelé.
Firetox
Le #14616241
Non manu le verrou dure le temps de la transaction
apres tout depend de comment sont faites les transaction sur SQLserver


tu fait un hlitBloque au debut de l'appli et a la fin tu libere ?

pourqoui le bloqué si tu as un crash et que l'enreg reste bloqué, tu peux
plus lancé l'appli


"Emmanuel Haefele" 46c45679$0$5109$
"Firetox"
par contre comme le parametre ROWLOCK n'est pas précise SQLServer va
poser des verrous de page ou de table c'est pour ca que parfois tu
bloque toutes la table ou si ton deuxieme poste essaye de locker un


enreg
dans la meme page il sera obligé d'attendre.



Là tu m'interpelles à nouveau car ce verrou je le pose au lancement de mon
appli et le retire à sa fermeture. D'après ce que tu me dis, mon
utilisateur risque d'attendre longtemps avant d'accèder à l'appli :-(

Est-ce que ça veut dire que je vais être obligé d'abandonner ce principe
et qu'il n'est pas exploitable avec en SQL ?


Amicalement,

Emmanuel Hafelé.



Emmanuel Haefele
Le #14616231
"Firetox"
tu fait un hlitBloque au debut de l'appli et a la fin tu libere ?



Oui

pourqoui le bloqué si tu as un crash et que l'enreg reste bloqué, tu
peux plus lancé l'appli



Si. Bloquer cet enregistrement me permet de contrôler que deux
utilisateurs n'utilisent pas simultanément le même login et s'il y a un
crash me permet justement de le constater car l'enregistrement existera
dans le fichier mais ne sera plus bloqué. Ce principe a toujours
fonctionné avec HF et je viens de le revérifier avec l'accès natif,
fonctionne à priori de cette manière aussi. Après crash le verrou est
libéré.


Amicalement,

Emmanuel Haefelé.
Firetox
Le #14616221
ca veut dire que le curseur (connexion ) utiliser a une transaction ouverte
tout le temps
et que les autres actions se feront sur d'autre curseurs : ce qui confirme
ce que disait karine avila, dans le fait qu'elle avait constaté que windev
prenait beaucouop de connexions pour un utilisateur.

par contre verifie quant meme qu'il n'y a pas un time out sur les
transactions, car sinon le serveur va la fermé et tu ne verra rien

bon dev
@+


"Emmanuel Haefele" 46c463e2$0$25930$
"Firetox"
tu fait un hlitBloque au debut de l'appli et a la fin tu libere ?



Oui

pourqoui le bloqué si tu as un crash et que l'enreg reste bloqué, tu
peux plus lancé l'appli



Si. Bloquer cet enregistrement me permet de contrôler que deux
utilisateurs n'utilisent pas simultanément le même login et s'il y a un
crash me permet justement de le constater car l'enregistrement existera
dans le fichier mais ne sera plus bloqué. Ce principe a toujours
fonctionné avec HF et je viens de le revérifier avec l'accès natif,
fonctionne à priori de cette manière aussi. Après crash le verrou est
libéré.


Amicalement,

Emmanuel Haefelé.



Emmanuel Haefele
Le #14616211
"Firetox"
Bonsoir Firetox,

par contre verifie quant meme qu'il n'y a pas un time out sur les
transactions, car sinon le serveur va la fermé et tu ne verra rien



Je crois que j'y vois un petit mieux grâce à tes conseils et vais donc
continuer mes investigations.

En tout les cas je te remercie pour tout.


Amicalement,

Emmanuel Haefelé.
Publicité
Poster une réponse
Anonyme