HTransactionDébut() / HTransactionFin()

Réal Phil a écrit :

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.

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.

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.

Le 08/02/2010 06:25, Réal Phil a écrit :

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.

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.

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...

Le 08/02/2010 06:25, Réal Phil a écrit :

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.

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.

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

Goof a écrit :

...

> - 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.

Merci beaucoup pour toutes ces réponses
explicites, c'est grandement apprécié.

Le 08/02/2010 16:52, Daireaux Jean-Baptiste a écrit :

Goof a écrit :

...

> - 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.

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

> - 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. (o n
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 te l
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 ?

Réal Phil a écrit :

- 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).
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 ?

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.

Le 11/02/2010 10:43, Daireaux Jean-Baptiste a écrit :

Réal Phil a écrit :

- 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).
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 ?

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.

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.

http://publib.boulder.ibm.com/infocenter/weahelp/5.1/index.jsp?topic=/com.ibm.websphere.db2e.doc/db2e_iso_levels.html


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
;-)