Utilisation des transactions

Le
wd_newbie
Bonjour,

j'ai une petite question concernant les concernant les transactions,
je n'ai pas de grande expérience avec celles-ci

Dans un application, je dois :

- créer / modifier des enregistrement d'entree / sortie
- selon ces entrees/ sorties, créer la facture qui va avec
- ajouter une ligne dans la compta.

seulemement , je voudrai mettre la possibilité, a la fin de ces
traitements, de ne pas valider les opérations (encaisser / annuler ) ,
avrai dire , je pense mettre cette possibilité avant l'entrée de la
ligne de compta , mais cela reste vrai pour annuler les 2 premières
opérations.

Est-ce que les transactions sont adaptées à ce genre de transaction :
je pensais faire :
//=
=
HTransactionDebut ()

=> créer les sorties
=> modifier les entrées
=> créer la facture

si bAnnuler = vrai alors
HTransactionAnnule()
retour
fin

HTransactionFin()
//

merci d'avance

Olivier
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
Daniel
Le #14657081
wd_newbie a écrit :
Bonjour,

j'ai une petite question concernant les concernant les transactions,
je n'ai pas de grande expérience avec celles-ci ...

Dans un application, je dois :

- créer / modifier des enregistrement d'entree / sortie
- selon ces entrees/ sorties, créer la facture qui va avec
- ajouter une ligne dans la compta.

seulemement , je voudrai mettre la possibilité, a la fin de ces
traitements, de ne pas valider les opérations (encaisser / annuler ) ,
avrai dire , je pense mettre cette possibilité avant l'entrée de la
ligne de compta , mais cela reste vrai pour annuler les 2 premières
opérations.

Est-ce que les transactions sont adaptées à ce genre de transaction :
je pensais faire :
//======================== > HTransactionDebut ()

=> créer les sorties
=> modifier les entrées
=> créer la facture

si bAnnuler = vrai alors
HTransactionAnnule()
retour
fin

HTransactionFin()
//======================= >
merci d'avance

Olivier




un lien qui explique les transactions
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1

HF est en read uncommited



--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
patrice
Le #14657071
"wd_newbie" news:
seulemement , je voudrai mettre la possibilité, a la fin de ces
traitements, de ne pas valider les opérations (encaisser / annuler ) ,
avrai dire , je pense mettre cette possibilité avant l'entrée de la
ligne de compta , mais cela reste vrai pour annuler les 2 premières
opérations.



Est-ce que les transactions sont adaptées à ce genre de transaction :
je pensais faire :



oui a condition qu'il n'y ait pas d'interaction avec l'utilisateur
(c'est "pas bien" d'avoir une transaction ouverte pendant qu'une boite de
dialogue attend la réponse de l'utilisateur)

il est tout a fait possible d'utiliser une transaction pour annuler ou pas
une suite d'enregistrement :
par exemple:

debut transaction
sortir les élements du stock
si stock<0 alors annulertransaction
sinon
lancer commande fournisseur
fintransaction

mais le bon sens voudrait quand meme que l'on double d'un test avant la
transaction:
si stock-qte<0 alors retour "fonction impossible"
debut transaction
sortir les élements du stock
si stock<0 alors annulertransaction
sinon
lancer commande fournisseur
fintransaction

du coup la transaction n'échoue en général que si 2 personnes font la sortie
en meme temps.
l'un va passer, l'autre va échouer
mat
Le #14657051
wd_newbie wrote:
...

Est-ce que les transactions sont adaptées à ce genre de transaction :
je pensais faire :
//======================== > HTransactionDebut ()

=> créer les sorties
=> modifier les entrées
=> créer la facture

si bAnnuler = vrai alors
HTransactionAnnule()
retour
fin

HTransactionFin()
//======================= >


...

Bonjour,

L'aide dit ceci:

"" Aucune interface utilisateur (fenêtre, état, ...) ne doit être
utilisée entre le début et la fin d'une transaction.

Toutes les opérations de transaction doivent être réalisées dans un même
traitement : la fonction HTransactionDébut et la fonction
HTransactionAnnule doivent être appelées depuis le même traitement :
code de clic d'un bouton, .... ""

donc, il faut concentrer toutes les écritures au moment d'appuyer p.ex.
un bouton Création de Facture. J'ai un programme ou je donne le choix
d'accepter toute une transaction avec OuiNon et ça marche sans problème,
je dois juste supprimer un enregistrement (parmi beaucoup d'autres) à la
main car il est ajouté avant le début de la transaction.


Salutations
Mat
mat
Le #14657041
Daniel wrote:

HF est en read uncommited




Bonjour,

je ne suis pas fort en transactions mais je les utilise dans des
conditions multi-utilisateurs depuis quelques années sans problème. Je
suppose que c'est dû au fait que les transactions verrouillent les
enregistrements à modifier en lecture et je fais de même lorsque je
modifie sans transaction. Pour les calculs sur données, les
enregistrements concernés sont également bloqués en écriture.

Il me semble qu'il ne devrait alors plus avoir de problème d'intégrité
des données ou est-ce que je me trompes?

Merci
Mat
Daniel
Le #14657001
mat a écrit :
Daniel wrote:

HF est en read uncommited




Bonjour,

je ne suis pas fort en transactions mais je les utilise dans des
conditions multi-utilisateurs depuis quelques années sans problème. Je
suppose que c'est dû au fait que les transactions verrouillent les
enregistrements à modifier en lecture et je fais de même lorsque je
modifie sans transaction. Pour les calculs sur données, les
enregistrements concernés sont également bloqués en écriture.

Il me semble qu'il ne devrait alors plus avoir de problème d'intégrité
des données ou est-ce que je me trompes?

Merci
Mat



Regarde le lien, tu as les explications qui sont documentées.
Le niveau, le plus élevé d'isolation est également le niveau le plus lent!


J'ai toutefois un doute, HF est peut être en Read commited?


--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Michel HERRSCHER
Le #14656921
Bonjour,

Juste une petite chose pas tellement informatique mais plutôt de gestion:

Qui attribue le numéro de facture ?
si tu dois avoir une continuité absolue de la séquence il ne faut
l'attribuer que juste avant de faire htransactionfin.
ou alors l'avoir dans un fichier paramètre que tu bloque durant ta
transaction pour éviter un doublon ou un trou.
( je déconseille idauto quel que soit le sgbd ) pour cela car annulation
transaction d'une facture = trou dans la séquence)

Enfin le lien à utiliser entre facture et détail facture ? : idauto ou
numéro de la facture ? les deux mon général à cause des archivages qui
peuvent ne pas maintenir les idauto...


En procédant ainsi tu peux avoir une interruption de traitement ( bouton
Annuler ou planté suivi de htransactionannule ou wdoptimiseur option annuler
transaction) sans gros soucis. Enfin pas de ce type.

A+
--
Michel HERRSCHER CONSULTANT
Tel : +33450870912
http://www.mhc.herrscher.fr
Président de WINDASSO - Association des utilisateurs WxxDEV(c)
http://www.windasso.org


Bonjour,

j'ai une petite question concernant les concernant les transactions,
je n'ai pas de grande expérience avec celles-ci ...

Dans un application, je dois :

- créer / modifier des enregistrement d'entree / sortie
- selon ces entrees/ sorties, créer la facture qui va avec
- ajouter une ligne dans la compta.

seulemement , je voudrai mettre la possibilité, a la fin de ces
traitements, de ne pas valider les opérations (encaisser / annuler ) ,
avrai dire , je pense mettre cette possibilité avant l'entrée de la
ligne de compta , mais cela reste vrai pour annuler les 2 premières
opérations.

Est-ce que les transactions sont adaptées à ce genre de transaction :
je pensais faire :
//======================== > HTransactionDebut ()

=> créer les sorties
=> modifier les entrées
=> créer la facture

si bAnnuler = vrai alors
HTransactionAnnule()
retour
fin

HTransactionFin()
//======================= >
merci d'avance

Olivier


wd_newbie
Le #14656901
On 17 mar, 09:40, "Michel HERRSCHER"
...

Enfin le lien à utiliser entre facture et détail facture ? : idauto ou
numéro de la facture ? les deux mon général à cause des archivage s qui
peuvent ne pas maintenir les idauto...



Merci pour tous ces renseignements , je vais essayer de compiler tout
ce que vous m'avez dit et essayer de mettre en pratique !

Juste un truc dans ce que tu m'as dit ,Michel : <i>" ... à cause des
archivages qui peuvent ne pas maintenir les idauto..."</i>
Je dois commencer a avoir peur ou pas ?
En general je me base sur le IDauto pour créér un identifiant unique
d'enregistrement, a moins que le fichier n'ait un identifiant unique
(numéro d'article par exemple) , mais pour le reste je me base sur les
IDauto.
Il aurait un risque lors des archivages ?

Amicalement

Olivier
Michel HERRSCHER
Le #14656881
Dans un message wd_newbie disait :

On 17 mar, 09:40, "Michel HERRSCHER"
...

Enfin le lien à utiliser entre facture et détail facture ? : idauto ou
numéro de la facture ? les deux mon général à cause des archivages qui
peuvent ne pas maintenir les idauto...



Merci pour tous ces renseignements , je vais essayer de compiler tout
ce que vous m'avez dit et essayer de mettre en pratique !

Juste un truc dans ce que tu m'as dit ,Michel : <i>" ... à cause des
archivages qui peuvent ne pas maintenir les idauto..."</i>
Je dois commencer a avoir peur ou pas ?
En general je me base sur le IDauto pour créér un identifiant unique
d'enregistrement, a moins que le fichier n'ait un identifiant unique
(numéro d'article par exemple) , mais pour le reste je me base sur les
IDauto.
Il aurait un risque lors des archivages ?




Tout dépend de la structure des fichiers archives.

Si c'est une exacte copie du fichier normal, l'archivage via hajoute avec
hfixeidauto (ou hcopieenreg avec hcopieidauto) fait que ton id auto original
sera préservé et que tes relations entre les tables seront maintenues.

Mais en général on fait l'archivage de façon plus "textuelle"
qu'informatique pour bien maintenir la capacité de relecture plus tard sans
conserver toutes les versions de projet permettant de lire les anciens
archivages. Dans ce cas il faut vraiment gérer ses propres ID pour éviter ce
genre de souci quitte à avoir un mini projet de consultation d'archives lié
à ce problème.

Attention ce ne sont que mes opinions. D'autres façons de gérer le problème
existent et ont leurs atouts comme leurs défauts. Le choix doivent être fait
selon les besoins du client.

Amicalement
--
Michel HERRSCHER CONSULTANT
Tel : +33450870912
http://www.mhc.herrscher.fr
Président de WINDASSO - Association des utilisateurs WxxDEV(c)
http://www.windasso.org
Publicité
Poster une réponse
Anonyme