HTransactionDébut() / HTransactionFin()
Réal Phil
[ HtransactionDébut() / HtransactionFin() ] même si cela m'aurait été
bien utile à plusieurs occasions.
J'aimerais l'avis de ceux qui utilisent ce concept avant de me lancer
dans l'aventure.
Est-ce aussi fiable qu'on le prétend ?
Y a-t-il des pièges à éviter ?
Est-ce que cela ralenti beaucoup les enregistrements ? Par exemple,
lors de l'enregistrement d'une facture ou il y a plusieurs fichiers à
mettre à jour.
J'ai bien lu les recommandations dans l'aide de WD8 et comment
rétablir la cohérence de la base de donnée en testant
HTransactionInterrompue() dans le code d'initialisation du projet. Est-
ce vraiment aussi simple ?
Toute réponse sera grandement appréciée.
Daireaux Jean-Baptiste
> J'ai toujours h�sit� � utiliser les transactions
> [ HtransactionD�but() / HtransactionFin() ] m�me si cela m'aurait �t�
> bien utile � plusieurs occasions.
>
> J'aimerais l'avis de ceux qui utilisent ce concept avant de me lancer
> dans l'aventure.
>
> Y a-t-il des pi�ges � �viter ?
> Est-ce que cela ralenti beaucoup les enregistrements ? Par exemple,
> mettre � jour.
>
> J'ai bien lu les recommandations dans l'aide de WD8 et comment
> HTransactionInterrompue() dans le code d'initialisation du projet. Est-
> ce vraiment aussi simple ?
>
Bonjour,
Nous avons commenc� � utiliser les transactions lors de notre passage
5.5 -> 7.5 sans regret.
Nous sommes actuellement en 11.
Les b�n�fices �tant sup�rieurs aux inconv�nients, nous sommes satisfait.
Les inconv�nients que nous avons rencontr� sont :
- Durant une transaction, les fichiers qui sont soumis � un
hbloquefichier/hdebloquefichier ne sont plus g�r�s par la transaction.
Donc pour ses fichiers, on les �carte de la gestion par transaction. (on
n'a pas v�rifier la gestion des blocages pour un enregistrement).
- L'annulation de la transaction ne se d�roule pas dans l'ordre inverse
de son ex�cution se qui entraine des erreurs lors de l'annulation �
cause de l'int�grit� r�f�rentielle. Du coup, on doit intervenir
manuellement pour pouvoir annuler la transaction.
- Attention � la r�cup�ration sur erreur (notre prog revient au menu si
une fen�tre explose) il faut v�rifier si il y a une transaction en cours
et l'annuler. Sinon l'utilisateur continue � travailler normalement et
risque de perdre des donn�es.
- Les enregistrements en transaction sont directement lisibles par les
autres postes connect�s � la base de donn�es avant la validation de la
transaction. Si la transaction est annul�e, ces enregistrements sont
effac�s. Cette particularit� peut entrainer des risques de trou dans la
num�rotation d'enregistrement g�r� par des compteurs manuel.( Nous ne
g�rons pas les compteur automatique donc nous n'avons pas contr�l� leur
comportement. )
Nous avons v�rifi� ces ph�nom�nes sur le WD75, et WD11 en hyperfile
classique. Nous projetons de basculer en hyperfile client/serveur, mais
comme nous voulons continuer � utiliser les transactions, � partir de
quelle version WinDev g�res-t-il les transactions en client /serveur ?
Car en WD11, elle ne sont pas g�r�e. Ont-elle le m�me comportement dans
ce mode client/serveur ?
J.B.D.
phig
> J'ai toujours h�sit� � utiliser les transactions
> [ HtransactionD�but() / HtransactionFin() ] m�me si cela m'aurait �t�
>
> J'aimerais l'avis de ceux qui utilisent ce concept avant de me lancer
> dans l'aventure.
>
> Est-ce que cela ralenti beaucoup les enregistrements ? Par exemple,
> mettre � jour.
>
> J'ai bien lu les recommandations dans l'aide de WD8 et comment
> HTransactionInterrompue() dans le code d'initialisation du projet. Est-
> ce vraiment aussi simple ?
>
bonjour
j'utilise les transaction sur HFCS depuis deux en production sur un
frontal webdev 200 connexions/j et un Backoffice windev avec 20 stations
sans AUCUN pb.
si tu g�res tes Htransactionannule dans le code d'exception de chaque
traitement, pas de pb particulier.
Je ne regrette pas ce choix, surtout avec le frontal webdev ou certains
ont la f�cheuse habitude de cliquer 10 fois sur le bouton de validation
quand ca va pas assez vite ( + de 3 secondes ;) )
my 2 cents...
Goof
> J'ai toujours h�sit� � utiliser les transactions
> [ HtransactionD�but() / HtransactionFin() ] m�me si cela m'aurait �t�
>
> J'aimerais l'avis de ceux qui utilisent ce concept avant de me lancer
> dans l'aventure.
>
> Est-ce que cela ralenti beaucoup les enregistrements ? Par exemple,
> mettre � jour.
>
> J'ai bien lu les recommandations dans l'aide de WD8 et comment
> HTransactionInterrompue() dans le code d'initialisation du projet. Est-
> ce vraiment aussi simple ?
>
Quelques points sur le fonctionnement:
- Ne pas oublier un HTransactionAnnule() sur les erreurs.
- Ni le HtransactionFin() quand tout va bien.
- Verifier a l'ouverture du programme avec HTransactionInterrompue() si
une transaction n'est pas termin� (et appeler HTransactionAnnule() pour
remettre les donn�es en �tat)
- Si possible 1 fichier de transaction (TRS) par poste/instance (PID de
l'exe ou autre comme variable dans le nom du fichier TRS)
- Comme dit plus haut les donn�es sont modifi� en temps r�el dans la base.
- Les blocages d'enregistrements modifi� sont automatique apr�s un
Hajoute/Hmodifie (un enregistrement ne peut �tre modifi� tant que la
transaction n'est pas termin�)
- A contrario, les enregistrements lu ne sont pas bloqu�. (il pourra
donc �tre modifi� par un autre utilisateur/process)
Sur la fiabilit� :
c'est fiable .... quand le reste est fiable.
En HF/classique sur partage windows, le probl�me est le cache windows et
les coupures r�seaux.
En effet �a m'est arriv� qu'un client fasse un saisie/impression et ait
ses impressions. Il plante apr�s et quand il red�marre le programme ...
plus rien.
Si le r�seau n'a pas de coupure, c'est fiable.
Les seul moyens de mettre en d�faut le m�canisme ont �t� de couper le
r�seau en plein milieu des op�rations ou une coupure de courant sur le
serveur.
En HF/CS
C'est le serveur qui fait la transaction de son cot�, mise a part la
coupure de courant , �a doit tenir.
Pour ce qui est des performances, je pense que la s�curit� apport� en
vaut largement la chandelle.
A++
Goof
Daireaux Jean-Baptiste
> ...
> - Si possible 1 fichier de transaction (TRS) par poste/instance (PID de
> l'exe ou autre comme variable dans le nom du fichier TRS)
>
> A++
> Goof
Bonjour,
Nous utilisons un seul fichier de transaction depuis la 75 pour nos
programmes multi-postes et nous avons pas eut de probl�mes pour
l'annulation des transactions. Quel est le probl�me li�e � ce conseille ?
J.B.D.
Réal Phil
explicites, c'est grandement apprécié.
Goof
En effet �a marche avec un seul fichier mais, en utilisant plusieurs
fichiers �a permet de le faire "disparaitre" apr�s chaque transaction.
En plus, le fichier contient le nom du poste qui l'a lanc�,
l'utilisateur de la base et l'application. (analyse partag� entre
plusieurs applications)
On sait donc mieux quelle machine a plant� et d'o� l'erreur peut venir.
Ca simplifie, aussi, un peut la recherche du probl�me quand une
transaction plante et/ou ne veut pas s'annuler.
Et , si on a besoin d'ouvrir le TRS pour v�rifier les op�rations, il n'y
a qu'une s�rie d'ordres et pas 3 ou 4 transactions en cours dedans.
A++
Goof
Réal Phil
> hbloquefichier/hdebloquefichier ne sont plus gérés par la transaction.
> Donc pour ses fichiers, on les écarte de la gestion par transaction. (on
> n'a pas vérifier la gestion des blocages pour un enregistrement).
> J.B.D.
Lors de l'enregistrement d'une facture environ 900 lignes de code sont
exécutées. Et comme nous n'utilisions pas les HTransactions..() avant
nous avons tout plein de HBloqueFichier/HDebloqueFichier avec blocage
en lecture et en écriture - en fait chaque fichier qui doit être mis à
jour a un blocage/déblocage. Est-ce que je dois comprendre que l'ajout
d'un HTransactionDébut() au début et un HTransactionFin() à la fin tel
quel sans rien changer aucune autre ligne de code ne servira à rien
parce qu'aucun de ces fichiers ne sera géré par HTransaction..() ?
C'est curieux, non ?
En réseau il est pourtant indispensable de bloquer la lecture des
données - particulièrement pour certaines données cumulatives (comme
un cumulatif du chiffre d'affaire d'une Client, etc...). D'ailleurs
l'aide dans WD8 le recommande fortement.
Est-ce que j'ai mal compris quelque chose ?
Daireaux Jean-Baptiste
>> hbloquefichier/hdebloquefichier ne sont plus g�r�s par la transaction.
>> Donc pour ses fichiers, on les �carte de la gestion par transaction. (on
>> n'a pas v�rifier la gestion des blocages pour un enregistrement).
>> J.B.D.
>
> Lors de l'enregistrement d'une facture environ 900 lignes de code sont
> nous avons tout plein de HBloqueFichier/HDebloqueFichier avec blocage
> jour a un blocage/d�blocage. Est-ce que je dois comprendre que l'ajout
> d'un HTransactionD�but() au d�but et un HTransactionFin() � la fin tel
> quel sans rien changer aucune autre ligne de code ne servira � rien
> parce qu'aucun de ces fichiers ne sera g�r� par HTransaction..() ?
> C'est curieux, non ?
>
> donn�es - particuli�rement pour certaines donn�es cumulatives (comme
> un cumulatif du chiffre d'affaire d'une Client, etc...). D'ailleurs
> l'aide dans WD8 le recommande fortement.
>
> Est-ce que j'ai mal compris quelque chose ?
Bonjour,
Je vous indique ce que nous avons constat� lors de nos tests de rollback
des transactions. nous avons des fichiers de cumul qui sont bloqu�s en
lecture par hbloquefichier/hdebloquefichier et il est apparu que ces
fichiers n'ont pas eu l'application du rollback bien qu'ils aient �t� en
transaction.
Ces tests ont �t� effectu�s � l'�poque sur le WD7.5 lors du choix
d'utiliser les transactions. Il faudrait les refaire sur la version de
WD que vous utilisez, et nous dire si c'est toujours un pbm d'actualit�.
Pour le blocage de la lecture des donn�es, la doc conseille de bloquer
les enregistements g�n�r�s pendant la transaction avec l'option
'hBlocageLectureEcriture' de hajoute et hmodifie.
cf Transactions : S�curisez vos traitements sur des fichiers Hyper File
Si votre code a �t� r�alis� pour g�rer manuellement les erreurs de
blocage, il ne devrait pas y avoir de soucis. Reste � garder la trace de
tous les enregistrements ajout�s/modifi�s pour les d�bloquer � la fin de
la transaction ...
De plus cela ne r�gle pas le probl�me des enregistrements supprim�s qui
eux seront effectivement plus visibles du reste du r�seau bien que la
transaction n'est pas �t� encore valid�e.
J.B.D.
Daniel
Bonjour,
r�ponse dans l'aide (WD10) :
"Remarque : Les transactions suivent la norme SQL 92 "READ UNCOMMITED".
Pour assurer la bonne coh�rence de vos donn�es, il est n�cessaire de
tenir compte de ce fonctionnement."
Bref c'est mieux que rien, mais c'est loin d'�tre s�cu pour la coh�rence
des donn�es dans le cadre o� il y a plusieurs utilisateurs, sauf si on
"bloque" syst�matiquement les enregistrements.
A priori c'est toujours les m�mes limites concernant les transactions en
HFSQL15
http://doc.pcsoft.fr/fr-FR/?3044337&name=transactions-mode-hyperfilesql-clientserveur
--
Daniel
;-)