est ce vous connaissez comment annul=E9 une transaction manuellement en
mode client serveur
car j'ai un message d'erreur : impossible d'annuler la
transaction :
Vous avez appel=E9 la fonction HTransactionAnnule.
Erreur renvoy=E9e par le serveur <SEV:4900> :
La transaction n'a pas pu =EAtre annul=E9e.
Le fichier de transaction est d=E9phas=E9 par rapport au fichier de
donn=E9es <Fichier.FIC>.
L'enregistrement n=B0<1> se trouve en dehors du fichier <Fichier>.
Si qu'il qu'un a une id=E9e je serai reconnaissant
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
Alexey K.
J'ai eu des corruptions HF (identifiants négatifs, etc ...) du temps de la version 9 et fichiers partagés sur Novell. Quand le serveur se plantait et les gens étaient sur la base (avec verrous positionnés et fichiers ouverts en écriture, merci). Ou bien quand un admin régional reboutait le serveur sans avertir personne.
Il y avait WDTrans ou quelque chose comme ca qui permettait de libérer toutes les transactions. J'ai également du supprimer des enregistrements a la main avec WDModFic il me semble. Cela a permis de corriger les problèmes dans 99% des cas.
En HFCS c'est pareil il suffit d'ouvrir les fichiers directement sur le serveur je suppose ?
On a eu également les 1% de cas ou s'était impossible (plantage de WDModFic lors de l'ouverture des fichiers). Recours aux sauvegardes de la veille. En effet quand les fichiers sont ouverts en écriture un reboot peut les endommager définitivement.
Et un cas dans un département ou les sauvegardes n'étaient pas à jour (petite structure, personne pour s'occuper de vérifier si les sauvegardes marchaient). Perte de données sur 3 mois : erreur, sanction, punition, châtiment. Sans appel.
Aujourd'hui je bosse pour une plus grosse structure qui a quelques moyens (40 personnes à la DSI). Tout tourne sur SQL Serveur, merci.
Enfin ... on rigolait bien quand même du temps des bases de données HF (non CS) en reseau.
Contacte le support technique, ils m'ont bien dépanné dans le temps.
Bon courage à toi.
Cordialement.
J'ai eu des corruptions HF (identifiants négatifs, etc ...) du temps
de la version 9 et fichiers partagés sur Novell. Quand le serveur se
plantait et les gens étaient sur la base (avec verrous positionnés et
fichiers ouverts en écriture, merci). Ou bien quand un admin régional
reboutait le serveur sans avertir personne.
Il y avait WDTrans ou quelque chose comme ca qui permettait de libérer
toutes les transactions. J'ai également du supprimer des
enregistrements a la main avec WDModFic il me semble. Cela a permis de
corriger les problèmes dans 99% des cas.
En HFCS c'est pareil il suffit d'ouvrir les fichiers directement
sur le serveur je suppose ?
On a eu également les 1% de cas ou s'était impossible (plantage de
WDModFic lors de l'ouverture des fichiers). Recours aux sauvegardes de
la veille. En effet quand les fichiers sont ouverts en écriture un
reboot peut les endommager définitivement.
Et un cas dans un département ou les sauvegardes n'étaient pas à
jour (petite structure, personne pour s'occuper de vérifier si les
sauvegardes marchaient). Perte de données sur 3 mois : erreur,
sanction, punition, châtiment. Sans appel.
Aujourd'hui je bosse pour une plus grosse structure qui a quelques
moyens (40 personnes à la DSI). Tout tourne sur SQL Serveur, merci.
Enfin ... on rigolait bien quand même du temps des bases de données
HF (non CS) en reseau.
Contacte le support technique,
ils m'ont bien dépanné dans le temps.
J'ai eu des corruptions HF (identifiants négatifs, etc ...) du temps de la version 9 et fichiers partagés sur Novell. Quand le serveur se plantait et les gens étaient sur la base (avec verrous positionnés et fichiers ouverts en écriture, merci). Ou bien quand un admin régional reboutait le serveur sans avertir personne.
Il y avait WDTrans ou quelque chose comme ca qui permettait de libérer toutes les transactions. J'ai également du supprimer des enregistrements a la main avec WDModFic il me semble. Cela a permis de corriger les problèmes dans 99% des cas.
En HFCS c'est pareil il suffit d'ouvrir les fichiers directement sur le serveur je suppose ?
On a eu également les 1% de cas ou s'était impossible (plantage de WDModFic lors de l'ouverture des fichiers). Recours aux sauvegardes de la veille. En effet quand les fichiers sont ouverts en écriture un reboot peut les endommager définitivement.
Et un cas dans un département ou les sauvegardes n'étaient pas à jour (petite structure, personne pour s'occuper de vérifier si les sauvegardes marchaient). Perte de données sur 3 mois : erreur, sanction, punition, châtiment. Sans appel.
Aujourd'hui je bosse pour une plus grosse structure qui a quelques moyens (40 personnes à la DSI). Tout tourne sur SQL Serveur, merci.
Enfin ... on rigolait bien quand même du temps des bases de données HF (non CS) en reseau.
Contacte le support technique, ils m'ont bien dépanné dans le temps.
Bon courage à toi.
Cordialement.
progwdm
bonjour,
Il me semble qu'en client/serveur, c'est le serveur qui annule automatiquement les transactions.
Mais contactez le ST pour confirmation.
bon dev
-- http://progwdm.blogspot.com/
bonjour,
Il me semble qu'en client/serveur, c'est le serveur qui annule
automatiquement les transactions.
Il me semble qu'en client/serveur, c'est le serveur qui annule automatiquement les transactions.
Mais contactez le ST pour confirmation.
bon dev
-- http://progwdm.blogspot.com/
AnasDev
Meci pour vos réponse j'ai trouvé la solution il faut supprimé les fichier de trasaction : TRSOperation.TRS et TRSOperationInfoClient.TRS car il sont endomagé c pour ca que le serveur n'as pas pu les supprimé
Alexey K. a écrit :
J'ai eu des corruptions HF (identifiants négatifs, etc ...) du temps de la version 9 et fichiers partagés sur Novell. Quand le serveur se plantait et les gens étaient sur la base (avec verrous positionnés et fichiers ouverts en écriture, merci). Ou bien quand un admin régional reboutait le serveur sans avertir personne.
Il y avait WDTrans ou quelque chose comme ca qui permettait de libérer toutes les transactions. J'ai également du supprimer des enregistrements a la main avec WDModFic il me semble. Cela a permis de corriger les problèmes dans 99% des cas.
En HFCS c'est pareil il suffit d'ouvrir les fichiers directement sur le serveur je suppose ?
On a eu également les 1% de cas ou s'était impossible (plantage de WDModFic lors de l'ouverture des fichiers). Recours aux sauvegardes de la veille. En effet quand les fichiers sont ouverts en écriture un reboot peut les endommager définitivement.
Et un cas dans un département ou les sauvegardes n'étaient pas à jour (petite structure, personne pour s'occuper de vérifier si les sauvegardes marchaient). Perte de données sur 3 mois : erreur, sanction, punition, châtiment. Sans appel.
Aujourd'hui je bosse pour une plus grosse structure qui a quelques moyens (40 personnes à la DSI). Tout tourne sur SQL Serveur, merci.
Enfin ... on rigolait bien quand même du temps des bases de données HF (non CS) en reseau.
Contacte le support technique, ils m'ont bien dépanné dans le temps.
Bon courage à toi.
Cordialement.
Meci pour vos réponse j'ai trouvé la solution
il faut supprimé les fichier de trasaction : TRSOperation.TRS et
TRSOperationInfoClient.TRS
car il sont endomagé c pour ca que le serveur n'as pas pu les
supprimé
Alexey K. a écrit :
J'ai eu des corruptions HF (identifiants négatifs, etc ...) du temps
de la version 9 et fichiers partagés sur Novell. Quand le serveur se
plantait et les gens étaient sur la base (avec verrous positionnés et
fichiers ouverts en écriture, merci). Ou bien quand un admin régional
reboutait le serveur sans avertir personne.
Il y avait WDTrans ou quelque chose comme ca qui permettait de libérer
toutes les transactions. J'ai également du supprimer des
enregistrements a la main avec WDModFic il me semble. Cela a permis de
corriger les problèmes dans 99% des cas.
En HFCS c'est pareil il suffit d'ouvrir les fichiers directement
sur le serveur je suppose ?
On a eu également les 1% de cas ou s'était impossible (plantage de
WDModFic lors de l'ouverture des fichiers). Recours aux sauvegardes de
la veille. En effet quand les fichiers sont ouverts en écriture un
reboot peut les endommager définitivement.
Et un cas dans un département ou les sauvegardes n'étaient pas à
jour (petite structure, personne pour s'occuper de vérifier si les
sauvegardes marchaient). Perte de données sur 3 mois : erreur,
sanction, punition, châtiment. Sans appel.
Aujourd'hui je bosse pour une plus grosse structure qui a quelques
moyens (40 personnes à la DSI). Tout tourne sur SQL Serveur, merci.
Enfin ... on rigolait bien quand même du temps des bases de données
HF (non CS) en reseau.
Contacte le support technique,
ils m'ont bien dépanné dans le temps.
Meci pour vos réponse j'ai trouvé la solution il faut supprimé les fichier de trasaction : TRSOperation.TRS et TRSOperationInfoClient.TRS car il sont endomagé c pour ca que le serveur n'as pas pu les supprimé
Alexey K. a écrit :
J'ai eu des corruptions HF (identifiants négatifs, etc ...) du temps de la version 9 et fichiers partagés sur Novell. Quand le serveur se plantait et les gens étaient sur la base (avec verrous positionnés et fichiers ouverts en écriture, merci). Ou bien quand un admin régional reboutait le serveur sans avertir personne.
Il y avait WDTrans ou quelque chose comme ca qui permettait de libérer toutes les transactions. J'ai également du supprimer des enregistrements a la main avec WDModFic il me semble. Cela a permis de corriger les problèmes dans 99% des cas.
En HFCS c'est pareil il suffit d'ouvrir les fichiers directement sur le serveur je suppose ?
On a eu également les 1% de cas ou s'était impossible (plantage de WDModFic lors de l'ouverture des fichiers). Recours aux sauvegardes de la veille. En effet quand les fichiers sont ouverts en écriture un reboot peut les endommager définitivement.
Et un cas dans un département ou les sauvegardes n'étaient pas à jour (petite structure, personne pour s'occuper de vérifier si les sauvegardes marchaient). Perte de données sur 3 mois : erreur, sanction, punition, châtiment. Sans appel.
Aujourd'hui je bosse pour une plus grosse structure qui a quelques moyens (40 personnes à la DSI). Tout tourne sur SQL Serveur, merci.
Enfin ... on rigolait bien quand même du temps des bases de données HF (non CS) en reseau.
Contacte le support technique, ils m'ont bien dépanné dans le temps.
Bon courage à toi.
Cordialement.
Emmanuel Haefelé
"AnasDev" a écrit :
Bonjour,
Meci pour vos réponse j'ai trouvé la solution il faut supprimé les fichier de trasaction : TRSOperation.TRS et TRSOperationInfoClient.TRS car il sont endomagé c pour ca que le serveur n'as pas pu les supprimé
En WinDev 5.5 avec HF classique j'utilisais également les transactions et avais souvent constaté ce même problème. Je procédais de la même manière que toi si je me souviens bien mais par la même occasion je perdais le bénéfice de la transaction (d'où d'ailleurs l'abandon de cette méthode). Est-ce que dans ton cas c'est la même chose, c'est comme si tu n'avais pas géré de transaction ?
Et si oui à quoi peut bien servir une transaction si on n'est pas certain qu'elle va jouer son rôle ?
Je pensais qu'en HF Client/serveur ce problème n'existerait plus mais j'ai l'impression que non, est-ce que je me trompe ?
Amicalement,
Emmanuel Haefelé.
"AnasDev" <youyou9@hotmail.com> a écrit :
Bonjour,
Meci pour vos réponse j'ai trouvé la solution
il faut supprimé les fichier de trasaction : TRSOperation.TRS et
TRSOperationInfoClient.TRS
car il sont endomagé c pour ca que le serveur n'as pas pu les
supprimé
En WinDev 5.5 avec HF classique j'utilisais également les transactions et
avais souvent constaté ce même problème. Je procédais de la même manière
que toi si je me souviens bien mais par la même occasion je perdais le
bénéfice de la transaction (d'où d'ailleurs l'abandon de cette méthode).
Est-ce que dans ton cas c'est la même chose, c'est comme si tu n'avais pas
géré de transaction ?
Et si oui à quoi peut bien servir une transaction si on n'est pas certain
qu'elle va jouer son rôle ?
Je pensais qu'en HF Client/serveur ce problème n'existerait plus mais j'ai
l'impression que non, est-ce que je me trompe ?
Meci pour vos réponse j'ai trouvé la solution il faut supprimé les fichier de trasaction : TRSOperation.TRS et TRSOperationInfoClient.TRS car il sont endomagé c pour ca que le serveur n'as pas pu les supprimé
En WinDev 5.5 avec HF classique j'utilisais également les transactions et avais souvent constaté ce même problème. Je procédais de la même manière que toi si je me souviens bien mais par la même occasion je perdais le bénéfice de la transaction (d'où d'ailleurs l'abandon de cette méthode). Est-ce que dans ton cas c'est la même chose, c'est comme si tu n'avais pas géré de transaction ?
Et si oui à quoi peut bien servir une transaction si on n'est pas certain qu'elle va jouer son rôle ?
Je pensais qu'en HF Client/serveur ce problème n'existerait plus mais j'ai l'impression que non, est-ce que je me trompe ?
Amicalement,
Emmanuel Haefelé.
regis.scotto
Salut Emmanuel, Salut a tous,
[le Sat, 13 Jan 2007 15:56:15 +0100] [dans "fr.comp.developpement.agl.windev"] [le message ayant pour sujet : "Re: Comment annulé une transaction en client-serveur"] ["Emmanuel Haefelé" ] écrivait :
../..
Et si oui à quoi peut bien servir une transaction si on n'est pas certain qu'elle va jouer son rôle ?
../..
Excusez mon ignorance, en effet, je n'ai jamais utilise les transactions, mais pouvez vous me dire a quoi sert la gestion des transactions ? Est ce un systeme de securisation de la gestion reseau ? Dans les cas de coupure/rupture de connexion avec la base ? Peut on utiliser les transactions en monoposte ou est ce inutile ?
Je vous remercie pour les reponses car cela pourrait peut etre m'aider a comprendre cette facette de programmation, par le fait, quand j'ai des coupures de courant dans les magasins ou j'ai installe mon programme de gestion de caisse enregistreuse, si l'onduleur ne tient pas, j'ai des corruptions de la base de donnees, est ce qu'en applicant les transactions, je mettrais un terme au erreur sur la base ?
Je connais aussi le cas de Hsecurite(), serait ce plutot cette commande qu'il serait bon d'inserer ?
En vous remerciant une nouvelle fois,
Bien amicalement,
Regis.
-- http://blog.bonifacio.com/
Salut Emmanuel, Salut a tous,
[le Sat, 13 Jan 2007 15:56:15 +0100]
[dans "fr.comp.developpement.agl.windev"]
[le message ayant pour sujet : "Re: Comment annulé une transaction en
client-serveur"]
["Emmanuel Haefelé" <e.haefele@wanadoo.fr>] écrivait :
../..
Et si oui à quoi peut bien servir une transaction si on n'est pas certain
qu'elle va jouer son rôle ?
../..
Excusez mon ignorance, en effet, je n'ai jamais utilise les
transactions, mais pouvez vous me dire a quoi sert la gestion des
transactions ? Est ce un systeme de securisation de la gestion reseau ?
Dans les cas de coupure/rupture de connexion avec la base ? Peut on
utiliser les transactions en monoposte ou est ce inutile ?
Je vous remercie pour les reponses car cela pourrait peut etre m'aider a
comprendre cette facette de programmation, par le fait, quand j'ai des
coupures de courant dans les magasins ou j'ai installe mon programme de
gestion de caisse enregistreuse, si l'onduleur ne tient pas, j'ai des
corruptions de la base de donnees, est ce qu'en applicant les
transactions, je mettrais un terme au erreur sur la base ?
Je connais aussi le cas de Hsecurite(), serait ce plutot cette commande
qu'il serait bon d'inserer ?
[le Sat, 13 Jan 2007 15:56:15 +0100] [dans "fr.comp.developpement.agl.windev"] [le message ayant pour sujet : "Re: Comment annulé une transaction en client-serveur"] ["Emmanuel Haefelé" ] écrivait :
../..
Et si oui à quoi peut bien servir une transaction si on n'est pas certain qu'elle va jouer son rôle ?
../..
Excusez mon ignorance, en effet, je n'ai jamais utilise les transactions, mais pouvez vous me dire a quoi sert la gestion des transactions ? Est ce un systeme de securisation de la gestion reseau ? Dans les cas de coupure/rupture de connexion avec la base ? Peut on utiliser les transactions en monoposte ou est ce inutile ?
Je vous remercie pour les reponses car cela pourrait peut etre m'aider a comprendre cette facette de programmation, par le fait, quand j'ai des coupures de courant dans les magasins ou j'ai installe mon programme de gestion de caisse enregistreuse, si l'onduleur ne tient pas, j'ai des corruptions de la base de donnees, est ce qu'en applicant les transactions, je mettrais un terme au erreur sur la base ?
Je connais aussi le cas de Hsecurite(), serait ce plutot cette commande qu'il serait bon d'inserer ?
En vous remerciant une nouvelle fois,
Bien amicalement,
Regis.
-- http://blog.bonifacio.com/
JeAn-PhI
Regis SCOTTO a utilisé son clavier pour écrire :
Salut Emmanuel, Salut a tous,
[le Sat, 13 Jan 2007 15:56:15 +0100] [dans "fr.comp.developpement.agl.windev"] [le message ayant pour sujet : "Re: Comment annulé une transaction en client-serveur"] ["Emmanuel Haefelé" ] écrivait :
../..
Et si oui à quoi peut bien servir une transaction si on n'est pas certain qu'elle va jouer son rôle ?
../..
Excusez mon ignorance, en effet, je n'ai jamais utilise les transactions, mais pouvez vous me dire a quoi sert la gestion des transactions ? Est ce un systeme de securisation de la gestion reseau ? Dans les cas de coupure/rupture de connexion avec la base ? Peut on utiliser les transactions en monoposte ou est ce inutile ?
Je vous remercie pour les reponses car cela pourrait peut etre m'aider a comprendre cette facette de programmation, par le fait, quand j'ai des coupures de courant dans les magasins ou j'ai installe mon programme de gestion de caisse enregistreuse, si l'onduleur ne tient pas, j'ai des corruptions de la base de donnees, est ce qu'en applicant les transactions, je mettrais un terme au erreur sur la base ?
Je connais aussi le cas de Hsecurite(), serait ce plutot cette commande qu'il serait bon d'inserer ?
En vous remerciant une nouvelle fois,
Bien amicalement,
Regis.
un exemple pour mieux comprendre est indiqué dans l'aide, il fait référence à un débit/crédit d'un compte bancaire sur un autre débit d'un compte A puis crédit sur un compte B avec transaction soit les 2 opérations réussissent soit rien n'est fait sans transaction on peut être débité sans être crédité
-- Cordialement JeAn-PhI
Regis SCOTTO a utilisé son clavier pour écrire :
Salut Emmanuel, Salut a tous,
[le Sat, 13 Jan 2007 15:56:15 +0100]
[dans "fr.comp.developpement.agl.windev"]
[le message ayant pour sujet : "Re: Comment annulé une transaction en
client-serveur"]
["Emmanuel Haefelé" <e.haefele@wanadoo.fr>] écrivait :
../..
Et si oui à quoi peut bien servir une transaction si on n'est pas certain
qu'elle va jouer son rôle ?
../..
Excusez mon ignorance, en effet, je n'ai jamais utilise les
transactions, mais pouvez vous me dire a quoi sert la gestion des
transactions ? Est ce un systeme de securisation de la gestion reseau ?
Dans les cas de coupure/rupture de connexion avec la base ? Peut on
utiliser les transactions en monoposte ou est ce inutile ?
Je vous remercie pour les reponses car cela pourrait peut etre m'aider a
comprendre cette facette de programmation, par le fait, quand j'ai des
coupures de courant dans les magasins ou j'ai installe mon programme de
gestion de caisse enregistreuse, si l'onduleur ne tient pas, j'ai des
corruptions de la base de donnees, est ce qu'en applicant les
transactions, je mettrais un terme au erreur sur la base ?
Je connais aussi le cas de Hsecurite(), serait ce plutot cette commande
qu'il serait bon d'inserer ?
En vous remerciant une nouvelle fois,
Bien amicalement,
Regis.
un exemple pour mieux comprendre est indiqué dans l'aide, il fait
référence à un débit/crédit d'un compte bancaire sur un autre
débit d'un compte A puis crédit sur un compte B avec transaction soit
les 2 opérations réussissent soit rien n'est fait sans transaction on
peut être débité sans être crédité
[le Sat, 13 Jan 2007 15:56:15 +0100] [dans "fr.comp.developpement.agl.windev"] [le message ayant pour sujet : "Re: Comment annulé une transaction en client-serveur"] ["Emmanuel Haefelé" ] écrivait :
../..
Et si oui à quoi peut bien servir une transaction si on n'est pas certain qu'elle va jouer son rôle ?
../..
Excusez mon ignorance, en effet, je n'ai jamais utilise les transactions, mais pouvez vous me dire a quoi sert la gestion des transactions ? Est ce un systeme de securisation de la gestion reseau ? Dans les cas de coupure/rupture de connexion avec la base ? Peut on utiliser les transactions en monoposte ou est ce inutile ?
Je vous remercie pour les reponses car cela pourrait peut etre m'aider a comprendre cette facette de programmation, par le fait, quand j'ai des coupures de courant dans les magasins ou j'ai installe mon programme de gestion de caisse enregistreuse, si l'onduleur ne tient pas, j'ai des corruptions de la base de donnees, est ce qu'en applicant les transactions, je mettrais un terme au erreur sur la base ?
Je connais aussi le cas de Hsecurite(), serait ce plutot cette commande qu'il serait bon d'inserer ?
En vous remerciant une nouvelle fois,
Bien amicalement,
Regis.
un exemple pour mieux comprendre est indiqué dans l'aide, il fait référence à un débit/crédit d'un compte bancaire sur un autre débit d'un compte A puis crédit sur un compte B avec transaction soit les 2 opérations réussissent soit rien n'est fait sans transaction on peut être débité sans être crédité
-- Cordialement JeAn-PhI
AnasDev
Salut Emmanuel salut tous
Une transaction sert de gérer par exemple les coupures d'électricité ,une machine qui plante au coure d'un traitement , par exemple si tu as un traitement que tu dois faire un Hajoute sur le fichier entête Commande et Hajoute sur le fichier Ligne de commande si dans ce cas le système enregistre dans le premier fichier et dans une 0.000001 seconde il avait une coupure de courant avant l'écriture dans le deuxième fichier , alors tu aura une entête sans détail , si tu fais ton traitement en transaction tu n'aura plus ce problème car toute la transaction sera annulée , alors même ta premier écriture dans le fichier commande sera annulée , et voila tu base de donnée sera correcte.
Emmanuel Haefelé a écrit :
"AnasDev" a écrit :
Bonjour,
> Meci pour vos réponse j'ai trouvé la solution > il faut supprimé les fichier de trasaction : TRSOperation.TRS et > TRSOperationInfoClient.TRS > car il sont endomagé c pour ca que le serveur n'as pas pu les > supprimé
En WinDev 5.5 avec HF classique j'utilisais également les transactions et avais souvent constaté ce même problème. Je procédais de la mêm e manière que toi si je me souviens bien mais par la même occasion je perdais le bénéfice de la transaction (d'où d'ailleurs l'abandon de cette mé thode). Est-ce que dans ton cas c'est la même chose, c'est comme si tu n'avais pas géré de transaction ?
Et si oui à quoi peut bien servir une transaction si on n'est pas certa in qu'elle va jouer son rôle ?
Je pensais qu'en HF Client/serveur ce problème n'existerait plus mais j 'ai l'impression que non, est-ce que je me trompe ?
Amicalement,
Emmanuel Haefelé.
Salut Emmanuel salut tous
Une transaction sert de gérer par exemple les coupures
d'électricité ,une machine qui plante au coure d'un traitement ,
par exemple si tu as un traitement que tu dois faire un Hajoute sur le
fichier entête Commande et Hajoute sur le fichier Ligne de commande si
dans ce cas le système enregistre dans le premier fichier et dans une
0.000001 seconde il avait une coupure de courant avant l'écriture
dans le deuxième fichier , alors tu aura une entête sans détail , si
tu fais ton traitement en transaction tu n'aura plus ce problème car
toute la transaction sera annulée , alors même ta premier écriture
dans le fichier commande sera annulée , et voila tu base de donnée
sera correcte.
Emmanuel Haefelé a écrit :
"AnasDev" <youyou9@hotmail.com> a écrit :
Bonjour,
> Meci pour vos réponse j'ai trouvé la solution
> il faut supprimé les fichier de trasaction : TRSOperation.TRS et
> TRSOperationInfoClient.TRS
> car il sont endomagé c pour ca que le serveur n'as pas pu les
> supprimé
En WinDev 5.5 avec HF classique j'utilisais également les transactions et
avais souvent constaté ce même problème. Je procédais de la mêm e manière
que toi si je me souviens bien mais par la même occasion je perdais le
bénéfice de la transaction (d'où d'ailleurs l'abandon de cette mé thode).
Est-ce que dans ton cas c'est la même chose, c'est comme si tu n'avais pas
géré de transaction ?
Et si oui à quoi peut bien servir une transaction si on n'est pas certa in
qu'elle va jouer son rôle ?
Je pensais qu'en HF Client/serveur ce problème n'existerait plus mais j 'ai
l'impression que non, est-ce que je me trompe ?
Une transaction sert de gérer par exemple les coupures d'électricité ,une machine qui plante au coure d'un traitement , par exemple si tu as un traitement que tu dois faire un Hajoute sur le fichier entête Commande et Hajoute sur le fichier Ligne de commande si dans ce cas le système enregistre dans le premier fichier et dans une 0.000001 seconde il avait une coupure de courant avant l'écriture dans le deuxième fichier , alors tu aura une entête sans détail , si tu fais ton traitement en transaction tu n'aura plus ce problème car toute la transaction sera annulée , alors même ta premier écriture dans le fichier commande sera annulée , et voila tu base de donnée sera correcte.
Emmanuel Haefelé a écrit :
"AnasDev" a écrit :
Bonjour,
> Meci pour vos réponse j'ai trouvé la solution > il faut supprimé les fichier de trasaction : TRSOperation.TRS et > TRSOperationInfoClient.TRS > car il sont endomagé c pour ca que le serveur n'as pas pu les > supprimé
En WinDev 5.5 avec HF classique j'utilisais également les transactions et avais souvent constaté ce même problème. Je procédais de la mêm e manière que toi si je me souviens bien mais par la même occasion je perdais le bénéfice de la transaction (d'où d'ailleurs l'abandon de cette mé thode). Est-ce que dans ton cas c'est la même chose, c'est comme si tu n'avais pas géré de transaction ?
Et si oui à quoi peut bien servir une transaction si on n'est pas certa in qu'elle va jouer son rôle ?
Je pensais qu'en HF Client/serveur ce problème n'existerait plus mais j 'ai l'impression que non, est-ce que je me trompe ?
Amicalement,
Emmanuel Haefelé.
Emmanuel Haefele
"Regis SCOTTO" a écrit dans le message de news:
Bonjour Régis,
Excusez mon ignorance, en effet, je n'ai jamais utilise les transactions, mais pouvez vous me dire a quoi sert la gestion des transactions ? Est ce un systeme de securisation de la gestion reseau ? Dans les cas de coupure/rupture de connexion avec la base ? Peut on utiliser les transactions en monoposte ou est ce inutile ?
Oui c'est pour gérer les coupures/ruptures de connexion réseau et JeAn-PhI te l'explique très bien.
Maintenant la gestion des transactions est plutôt à utiliser en réseau mais peut aussi théoriquement être utilisée (je suppose) en mono-poste. Par contre en mono-poste je ne sais vraiment pas si je m'y risquerais notamment en HF car dans ce cas tu dois avoir un risque énorme de corruption de ton fichier de transaction qui la rendrait finalement totalement inopérante. si tu souhaites sécuriser ton appli en mono-poste préfère largement un onduleur sur le poste car ce que tu risques le plus en fin de compte et à la condition que ton appli soit stable, c'est une coupure de courant.
Amicalement,
Emmanuel Haefelé.
"Regis SCOTTO" <regis.scotto@wanadoo.fr> a écrit dans le message de
news:45ad3859.2687521@news.orange.fr...
Bonjour Régis,
Excusez mon ignorance, en effet, je n'ai jamais utilise les
transactions, mais pouvez vous me dire a quoi sert la gestion des
transactions ? Est ce un systeme de securisation de la gestion reseau ?
Dans les cas de coupure/rupture de connexion avec la base ? Peut on
utiliser les transactions en monoposte ou est ce inutile ?
Oui c'est pour gérer les coupures/ruptures de connexion réseau et JeAn-PhI
te l'explique très bien.
Maintenant la gestion des transactions est plutôt à utiliser en réseau
mais peut aussi théoriquement être utilisée (je suppose) en mono-poste.
Par contre en mono-poste je ne sais vraiment pas si je m'y risquerais
notamment en HF car dans ce cas tu dois avoir un risque énorme de
corruption de ton fichier de transaction qui la rendrait finalement
totalement inopérante. si tu souhaites sécuriser ton appli en mono-poste
préfère largement un onduleur sur le poste car ce que tu risques le plus
en fin de compte et à la condition que ton appli soit stable, c'est une
coupure de courant.
Excusez mon ignorance, en effet, je n'ai jamais utilise les transactions, mais pouvez vous me dire a quoi sert la gestion des transactions ? Est ce un systeme de securisation de la gestion reseau ? Dans les cas de coupure/rupture de connexion avec la base ? Peut on utiliser les transactions en monoposte ou est ce inutile ?
Oui c'est pour gérer les coupures/ruptures de connexion réseau et JeAn-PhI te l'explique très bien.
Maintenant la gestion des transactions est plutôt à utiliser en réseau mais peut aussi théoriquement être utilisée (je suppose) en mono-poste. Par contre en mono-poste je ne sais vraiment pas si je m'y risquerais notamment en HF car dans ce cas tu dois avoir un risque énorme de corruption de ton fichier de transaction qui la rendrait finalement totalement inopérante. si tu souhaites sécuriser ton appli en mono-poste préfère largement un onduleur sur le poste car ce que tu risques le plus en fin de compte et à la condition que ton appli soit stable, c'est une coupure de courant.
Amicalement,
Emmanuel Haefelé.
Dc
Bonjour,
Emmanuel Haefele a exposé le 15/01/2007 :
Par contre en mono-poste je ne sais vraiment pas si je m'y risquerais notamment en HF car dans ce cas tu dois avoir un risque énorme de
C'est tres utile en monoposte aussi. Dans un traitement complexe, si tu veux laisser a l'utilisateur la possibilité d'annuler le travail fait, hop, tu annules la transaction. Et il reste la securité de bases coherentes en cas de plantage. Y a pas que les coupure reseau, y a les coupures tout court . :-))
a plus.
-- ------------------------------------------------------------- www.ctc-soft.com NOUV : Logiciel de Gestion Documentaire Comptabilité shareware Logiciels de Gestion de saisie terrain Spécialisé Tournées de boulangers -------------------------------------------------------------
Bonjour,
Emmanuel Haefele a exposé le 15/01/2007 :
Par contre en mono-poste je ne sais vraiment pas si je m'y risquerais
notamment en HF car dans ce cas tu dois avoir un risque énorme de
C'est tres utile en monoposte aussi.
Dans un traitement complexe, si tu veux laisser a l'utilisateur la
possibilité d'annuler le travail fait, hop, tu annules la transaction.
Et il reste la securité de bases coherentes en cas de plantage.
Y a pas que les coupure reseau, y a les coupures tout court . :-))
a plus.
--
-------------------------------------------------------------
www.ctc-soft.com
NOUV : Logiciel de Gestion Documentaire
Comptabilité shareware
Logiciels de Gestion de saisie terrain
Spécialisé Tournées de boulangers
-------------------------------------------------------------
Par contre en mono-poste je ne sais vraiment pas si je m'y risquerais notamment en HF car dans ce cas tu dois avoir un risque énorme de
C'est tres utile en monoposte aussi. Dans un traitement complexe, si tu veux laisser a l'utilisateur la possibilité d'annuler le travail fait, hop, tu annules la transaction. Et il reste la securité de bases coherentes en cas de plantage. Y a pas que les coupure reseau, y a les coupures tout court . :-))
a plus.
-- ------------------------------------------------------------- www.ctc-soft.com NOUV : Logiciel de Gestion Documentaire Comptabilité shareware Logiciels de Gestion de saisie terrain Spécialisé Tournées de boulangers -------------------------------------------------------------
Emmanuel Haefelé
"Dc" a écrit:
C'est tres utile en monoposte aussi. Dans un traitement complexe, si tu veux laisser a l'utilisateur la possibilité d'annuler le travail fait, hop, tu annules la transaction. Et il reste la securité de bases coherentes en cas de plantage. Y a pas que les coupure reseau, y a les coupures tout court . :-))
Oui finalement c'est exact, je n'avais jamais eu un tel besoin ou pensé à une telle utilisation des transactions ...
Amicalement,
Emmanuel Haefelé.
"Dc" <dc@ctc-soft.com> a écrit:
C'est tres utile en monoposte aussi.
Dans un traitement complexe, si tu veux laisser a l'utilisateur la
possibilité d'annuler le travail fait, hop, tu annules la transaction.
Et il reste la securité de bases coherentes en cas de plantage.
Y a pas que les coupure reseau, y a les coupures tout court . :-))
Oui finalement c'est exact, je n'avais jamais eu un tel besoin ou pensé à
une telle utilisation des transactions ...
C'est tres utile en monoposte aussi. Dans un traitement complexe, si tu veux laisser a l'utilisateur la possibilité d'annuler le travail fait, hop, tu annules la transaction. Et il reste la securité de bases coherentes en cas de plantage. Y a pas que les coupure reseau, y a les coupures tout court . :-))
Oui finalement c'est exact, je n'avais jamais eu un tel besoin ou pensé à une telle utilisation des transactions ...
