j'ai une petite question concernant les concernant les transactions,
je n'ai pas de grande exp=E9rience avec celles-ci ...
Dans un application, je dois :
- cr=E9er / modifier des enregistrement d'entree / sortie
- selon ces entrees/ sorties, cr=E9er la facture qui va avec
- ajouter une ligne dans la compta.
seulemement , je voudrai mettre la possibilit=E9, a la fin de ces
traitements, de ne pas valider les op=E9rations (encaisser / annuler ) ,
avrai dire , je pense mettre cette possibilit=E9 avant l'entr=E9e de la
ligne de compta , mais cela reste vrai pour annuler les 2 premi=E8res
op=E9rations.
Est-ce que les transactions sont adapt=E9es =E0 ce genre de transaction :
je pensais faire :
//=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
HTransactionDebut ()
=3D> cr=E9er les sorties
=3D> modifier les entr=E9es
=3D> cr=E9er la facture
si bAnnuler =3D vrai alors
HTransactionAnnule()
retour
fin
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Daniel
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
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 ;-)
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
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
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
"wd_newbie" a écrit dans le message de 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
"wd_newbie" <wd_newbie@romandie.com> a écrit dans le message de
news:1174046450.564442.308320@o5g2000hsb.googlegroups.com...
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
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
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
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.
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
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 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?
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
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 ;-)
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
;-)
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
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
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
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
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
On 17 mar, 09:40, "Michel HERRSCHER" <m...@herrscher.fr> wrote:
...
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 ?
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
Dans un message wd_newbie disait :
On 17 mar, 09:40, "Michel HERRSCHER" wrote:
...
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
Dans un message wd_newbie disait :
On 17 mar, 09:40, "Michel HERRSCHER" <m...@herrscher.fr> wrote:
...
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
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
