Historique Adrien a diffusé une news de titou, concernant les problèmes
d'identifiants sur hyperfile, car Titou ne devait pas savoir poster ;-)
dans le forum de l'éditeur.
Discussion très intéressante alimentée par Elian Lacroix.
Qui nous fait une grosse théorie sur le comment est géré l'IDautomatique
On apprend sur son site qu'il y a bien des problèmes, mais que faute de
savoir pourquoi, il est préférable de contourner cet incident avec une
solution qu'il propose.
Ma question basique, qui dit Ok maintenant si on travaille avec les
transactions il devrait pas y avoir de problème (car les transactions
sont bien là pour pallier les défaillances matériels).
Puis, Elian part dans des généralités où ce n'est pas de sa faute mais
c'est la faute du voisin. On botte en touche, en essayant de
décridibiliser l'intervenant (Manu).
Bref, à priori le sujet est maintenant fermé, donc Titou tu te
débrouilles avec tes doublons sur clé unique. Maintenant que tu sais que
cela peut exister tu cherches une solution ;-)
Mais attendu que Elian refuse de répondre sur l'aspect transctionnel
d'un ensemble d'opération qui devrait éviter cet incident, cela est un
manque de transparence flagrant et inquiètant.
Je suis surpris, d'apprendre qu'une clé unique puisse être doublée voire
plus sur HyperFile, car même sur une base avec index endommagés sur
MySQL en MyISAM, nous avons déjà eu des index endommagés suite à
plusieurs coupures de courant (successives) sur le serveur (suite à la
foudre), on n'a jamais eu de doublon sur une clé unique (et au pire un
refus d'enregistrement, qui nous a rappeler à l'ordre pour faire un
contôle des index).
Pourtant MyIsam est du fichier indexé, aussi.
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
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
Adrien
Salut,
Je trouve que tu fais de la désinformation.
Je viens de relire l'article sur le blog de Elian Lacroix et je trouve qu'il dit le contraire de ce que tu décris :
Daniel >>> On apprend sur son site qu'il y a bien des problèmes, E-L >> Il m'est arrivé sur un site en exploitation d'avoir une erreur de doublon sur cet identifiant automatique.
Daniel >>faute de savoir pourquoi, il est préférable de contourner cet incident avec une solution qu'il propose.... E-L >> Dans pareil cas, une possibilité serait de contourner immédiatement par un traitement forçant l'ajout, urgence d'une programmation tête dans le guidon, code vu aujourd'hui sur un forum. Mais une bien meilleure démarche, consiste à se documenter sur le principe de fonctionnement, afin de connaître les causes possibles.
etc...
A+ Adrien
Daniel a écrit :
Historique Adrien a diffusé une news de titou, concernant les problèm es d'identifiants sur hyperfile, car Titou ne devait pas savoir poster ;-) dans le forum de l'éditeur.
Discussion très intéressante alimentée par Elian Lacroix.
Qui nous fait une grosse théorie sur le comment est géré l'IDautoma tique On apprend sur son site qu'il y a bien des problèmes, mais que faute de savoir pourquoi, il est préférable de contourner cet incident avec une solution qu'il propose.
Ma question basique, qui dit Ok maintenant si on travaille avec les transactions il devrait pas y avoir de problème (car les transactions sont bien là pour pallier les défaillances matériels).
Puis, Elian part dans des généralités où ce n'est pas de sa faute mais c'est la faute du voisin. On botte en touche, en essayant de décridibiliser l'intervenant (Manu).
Bref, à priori le sujet est maintenant fermé, donc Titou tu te débrouilles avec tes doublons sur clé unique. Maintenant que tu sais que cela peut exister tu cherches une solution ;-)
Mais attendu que Elian refuse de répondre sur l'aspect transctionnel d'un ensemble d'opération qui devrait éviter cet incident, cela est un manque de transparence flagrant et inquiètant.
Je suis surpris, d'apprendre qu'une clé unique puisse être doublée voire plus sur HyperFile, car même sur une base avec index endommagés sur MySQL en MyISAM, nous avons déjà eu des index endommagés suite à plusieurs coupures de courant (successives) sur le serveur (suite à la foudre), on n'a jamais eu de doublon sur une clé unique (et au pire un refus d'enregistrement, qui nous a rappeler à l'ordre pour faire un contôle des index). Pourtant MyIsam est du fichier indexé, aussi.
Je viens de relire l'article sur le blog de Elian Lacroix et je trouve
qu'il dit le contraire de ce que tu décris :
Daniel >>> On apprend sur son site qu'il y a bien des problèmes,
E-L >> Il m'est arrivé sur un site en exploitation d'avoir une erreur
de doublon sur cet identifiant automatique.
Daniel >>faute de savoir pourquoi, il est préférable de contourner
cet incident avec une
solution qu'il propose....
E-L >> Dans pareil cas, une possibilité serait de contourner
immédiatement par un traitement forçant l'ajout, urgence d'une
programmation tête dans le guidon, code vu aujourd'hui sur un forum.
Mais une bien meilleure démarche, consiste à se documenter sur le
principe de fonctionnement, afin de connaître les causes possibles.
etc...
A+
Adrien
Daniel a écrit :
Historique Adrien a diffusé une news de titou, concernant les problèm es
d'identifiants sur hyperfile, car Titou ne devait pas savoir poster ;-)
dans le forum de l'éditeur.
Discussion très intéressante alimentée par Elian Lacroix.
Qui nous fait une grosse théorie sur le comment est géré l'IDautoma tique
On apprend sur son site qu'il y a bien des problèmes, mais que faute de
savoir pourquoi, il est préférable de contourner cet incident avec une
solution qu'il propose.
Ma question basique, qui dit Ok maintenant si on travaille avec les
transactions il devrait pas y avoir de problème (car les transactions
sont bien là pour pallier les défaillances matériels).
Puis, Elian part dans des généralités où ce n'est pas de sa faute mais
c'est la faute du voisin. On botte en touche, en essayant de
décridibiliser l'intervenant (Manu).
Bref, à priori le sujet est maintenant fermé, donc Titou tu te
débrouilles avec tes doublons sur clé unique. Maintenant que tu sais que
cela peut exister tu cherches une solution ;-)
Mais attendu que Elian refuse de répondre sur l'aspect transctionnel
d'un ensemble d'opération qui devrait éviter cet incident, cela est un
manque de transparence flagrant et inquiètant.
Je suis surpris, d'apprendre qu'une clé unique puisse être doublée voire
plus sur HyperFile, car même sur une base avec index endommagés sur
MySQL en MyISAM, nous avons déjà eu des index endommagés suite à
plusieurs coupures de courant (successives) sur le serveur (suite à la
foudre), on n'a jamais eu de doublon sur une clé unique (et au pire un
refus d'enregistrement, qui nous a rappeler à l'ordre pour faire un
contôle des index).
Pourtant MyIsam est du fichier indexé, aussi.
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Je viens de relire l'article sur le blog de Elian Lacroix et je trouve qu'il dit le contraire de ce que tu décris :
Daniel >>> On apprend sur son site qu'il y a bien des problèmes, E-L >> Il m'est arrivé sur un site en exploitation d'avoir une erreur de doublon sur cet identifiant automatique.
Daniel >>faute de savoir pourquoi, il est préférable de contourner cet incident avec une solution qu'il propose.... E-L >> Dans pareil cas, une possibilité serait de contourner immédiatement par un traitement forçant l'ajout, urgence d'une programmation tête dans le guidon, code vu aujourd'hui sur un forum. Mais une bien meilleure démarche, consiste à se documenter sur le principe de fonctionnement, afin de connaître les causes possibles.
etc...
A+ Adrien
Daniel a écrit :
Historique Adrien a diffusé une news de titou, concernant les problèm es d'identifiants sur hyperfile, car Titou ne devait pas savoir poster ;-) dans le forum de l'éditeur.
Discussion très intéressante alimentée par Elian Lacroix.
Qui nous fait une grosse théorie sur le comment est géré l'IDautoma tique On apprend sur son site qu'il y a bien des problèmes, mais que faute de savoir pourquoi, il est préférable de contourner cet incident avec une solution qu'il propose.
Ma question basique, qui dit Ok maintenant si on travaille avec les transactions il devrait pas y avoir de problème (car les transactions sont bien là pour pallier les défaillances matériels).
Puis, Elian part dans des généralités où ce n'est pas de sa faute mais c'est la faute du voisin. On botte en touche, en essayant de décridibiliser l'intervenant (Manu).
Bref, à priori le sujet est maintenant fermé, donc Titou tu te débrouilles avec tes doublons sur clé unique. Maintenant que tu sais que cela peut exister tu cherches une solution ;-)
Mais attendu que Elian refuse de répondre sur l'aspect transctionnel d'un ensemble d'opération qui devrait éviter cet incident, cela est un manque de transparence flagrant et inquiètant.
Je suis surpris, d'apprendre qu'une clé unique puisse être doublée voire plus sur HyperFile, car même sur une base avec index endommagés sur MySQL en MyISAM, nous avons déjà eu des index endommagés suite à plusieurs coupures de courant (successives) sur le serveur (suite à la foudre), on n'a jamais eu de doublon sur une clé unique (et au pire un refus d'enregistrement, qui nous a rappeler à l'ordre pour faire un contôle des index). Pourtant MyIsam est du fichier indexé, aussi.
Chacun est libre de penser ce qu'il veut. Mais des doublons sur un index unique je trouve cela très grave. Imagine, qu'un injecteur de Morphine piloter par une base qui fait des doublons sur une clé unique, le type va bien roupiller.
Mais pour l'instant tu n'as toujours pas répondu à la liste des 2 dysfonctionnements que je t'ai signalé en bottant en touche. "En disant que tu n'allais pas réinstaller WD7.5"
Je te cite dans le thread original Adrien a dit :"Je ne cherches pas à te démontrer l'inverse, je suis sûr que tu ne râle pas dans le vide. Je voulais juste tempérer ton message. Il est vrai que je n'ai pas de bug de wd7.5 qui me gêne." C'est normal puisque tu n'as plus WD7.5 d'installer!Non?
Ce n'est pas la peine que tu perdes du temps à faire le test sur WD10, car des internautes sur cette liste ont pris le temps de faire le test.
Et le résultat est le même entre WD7.5 et Windev 10, malheureusement.
Maintenant sur certaines TDF régionales on va peut être improviser une séance questions/réponses histoire de voir où en est l'éditeur? Que penses tu de cet idée? C'est WIN-WIN, pour les clients et l'éditeur.
1 /-Concernant crypte/décrypte je pense que c'est la RFC3548 qui doit être fausse, car depuis la 7.5 le base64 produit est erroné, même en 10-62e!
Concernant la fonction PING1 c'est simplement l'ordre des variables qui est primordial dans leur déclaration. Pourquoi mystère, mais beaucoup de temps de perdu pour trouver la solution.
J'offre cette fonction à la communauté Windev (enfin penser à la corriger, c'est un PING à la Windows, totalement paramétrable)
Pour que la procédure locale PINGD fonctionne croiser les variables "j est entier" avec "XReplyData est un entier sans signe".
PROCEDURE PINGD(pAdresse est une chaîne,pBoucle est entier = 1,pTimeOut est entier %0) j est entier
IP_OPTION_INFORMATION est une structure TTL est un entier sans signe sur 1 octet Tos est un entier sans signe sur 1 octet Flags est un entier sans signe sur 1 octet OptionsSize est un entier sans signe OptionsData est une chaîne fixe sur 128 FIN
IP_ECHO_REPLY est une structure Address est un tableau fixe de 4 entier sur 1 octet sans signe Status est un entier sans signe RoundTripTime est un entier sans signe DataSize est entier sans signe Reserved est un entier sans signe data est un entier sans signe Options est un IP_OPTION_INFORMATION FIN XL_EchoReply est un IP_ECHO_REPLY XL_OptInfo est un IP_OPTION_INFORMATION XIpAdress est un entier sans signe XretVal est un entier XSize est un entier XhIcmp est un entier sans signe Xerror est entier XVmoy est entier XReplyData est un entier sans signe
XSize = Dimension(XL_EchoReply)
XIpAdress = AppelDLL32("Wsock32", "inet_addr", pAdresse) SI XIpAdress = 0xFFFFFFFF ALORS Info("Adresse non conforme") RETOUR FIN
POUR j= 1 A pBoucle XIpAdress = AppelDLL32("Wsock32", "inet_addr", pAdresse) XhIcmp = AppelDLL32("icmp", "IcmpCreateFile") XretVal = AppelDLL32("icmp", "IcmpSendEcho", XhIcmp, XIpAdress,Répète("A",32), 32, Null, &XReplyData, XSize, pTimeOut) Transfert(&XL_EchoReply,&XReplyData,XSize) SELON XL_EchoReply:Status CAS 0 : Trace("Réponse de "+XL_EchoReply:Address[1]+"."+XL_EchoReply:Address[2]+"."+XL_EchoReply:Address[3]+"."+... XL_EchoReply:Address[4]+" : Octets="+XL_EchoReply:DataSize+" temps="+XL_EchoReply:RoundTripTime+" ms"+" Satut :"+Remplace(XL_EchoReply:Status[[1]],0,"Ok")) XVmoy+=XL_EchoReply:RoundTripTime AUTRE CAS : Xerror++ FIN FIN AppelDLL32("icmp", "IcmpCloseHandle", XhIcmp) Info("Succes : "+Val(j-1-Xerror),"Erreur : "+Xerror,"Vitesse Moyenne : "+PartieEntière(Val(XVmoy/(j-1))))
Chacun est libre de penser ce qu'il veut. Mais des doublons sur un index
unique je trouve cela très grave. Imagine, qu'un injecteur de Morphine
piloter par une base qui fait des doublons sur une clé unique, le type
va bien roupiller.
Mais pour l'instant tu n'as toujours pas répondu à la liste des 2
dysfonctionnements que je t'ai signalé en bottant en touche.
"En disant que tu n'allais pas réinstaller WD7.5"
Je te cite dans le thread original Adrien a dit :"Je ne cherches pas à
te démontrer l'inverse, je suis sûr que tu ne râle pas dans le vide. Je
voulais juste tempérer ton message. Il est vrai que je n'ai pas de bug
de wd7.5 qui me gêne."
C'est normal puisque tu n'as plus WD7.5 d'installer!Non?
Ce n'est pas la peine que tu perdes du temps à faire le test sur WD10,
car des internautes sur cette liste ont pris le temps de faire le test.
Et le résultat est le même entre WD7.5 et Windev 10, malheureusement.
Maintenant sur certaines TDF régionales on va peut être improviser une
séance questions/réponses histoire de voir où en est l'éditeur? Que
penses tu de cet idée?
C'est WIN-WIN, pour les clients et l'éditeur.
1 /-Concernant crypte/décrypte je pense que c'est la RFC3548 qui doit
être fausse, car depuis la 7.5 le base64 produit est erroné, même en 10-62e!
donc l'info d'Elian sur
http://www.codyx.org/snippet_codage-decodage-base64_164.aspx
est également erronée.
Concernant la fonction PING1 c'est simplement l'ordre des variables qui
est primordial dans leur déclaration. Pourquoi mystère, mais beaucoup de
temps de perdu pour trouver la solution.
J'offre cette fonction à la communauté Windev (enfin penser à la
corriger, c'est un PING à la Windows, totalement paramétrable)
Pour que la procédure locale PINGD fonctionne croiser les variables "j
est entier" avec "XReplyData est un entier sans signe".
PROCEDURE PINGD(pAdresse est une chaîne,pBoucle est entier = 1,pTimeOut
est entier %0)
j est entier
IP_OPTION_INFORMATION est une structure
TTL est un entier sans signe sur 1 octet
Tos est un entier sans signe sur 1 octet
Flags est un entier sans signe sur 1 octet
OptionsSize est un entier sans signe
OptionsData est une chaîne fixe sur 128
FIN
IP_ECHO_REPLY est une structure
Address est un tableau fixe de 4 entier sur 1 octet sans signe
Status est un entier sans signe
RoundTripTime est un entier sans signe
DataSize est entier sans signe
Reserved est un entier sans signe
data est un entier sans signe
Options est un IP_OPTION_INFORMATION
FIN
XL_EchoReply est un IP_ECHO_REPLY
XL_OptInfo est un IP_OPTION_INFORMATION
XIpAdress est un entier sans signe
XretVal est un entier
XSize est un entier
XhIcmp est un entier sans signe
Xerror est entier
XVmoy est entier
XReplyData est un entier sans signe
XSize = Dimension(XL_EchoReply)
XIpAdress = AppelDLL32("Wsock32", "inet_addr", pAdresse)
SI XIpAdress = 0xFFFFFFFF ALORS
Info("Adresse non conforme")
RETOUR
FIN
POUR j= 1 A pBoucle
XIpAdress = AppelDLL32("Wsock32", "inet_addr", pAdresse)
XhIcmp = AppelDLL32("icmp", "IcmpCreateFile")
XretVal = AppelDLL32("icmp", "IcmpSendEcho", XhIcmp,
XIpAdress,Répète("A",32), 32, Null, &XReplyData, XSize, pTimeOut)
Transfert(&XL_EchoReply,&XReplyData,XSize)
SELON XL_EchoReply:Status
CAS 0 :
Trace("Réponse de
"+XL_EchoReply:Address[1]+"."+XL_EchoReply:Address[2]+"."+XL_EchoReply:Address[3]+"."+...
XL_EchoReply:Address[4]+" : Octets="+XL_EchoReply:DataSize+"
temps="+XL_EchoReply:RoundTripTime+" ms"+" Satut
:"+Remplace(XL_EchoReply:Status[[1]],0,"Ok"))
XVmoy+=XL_EchoReply:RoundTripTime
AUTRE CAS :
Xerror++
FIN
FIN
AppelDLL32("icmp", "IcmpCloseHandle", XhIcmp)
Info("Succes : "+Val(j-1-Xerror),"Erreur : "+Xerror,"Vitesse Moyenne :
"+PartieEntière(Val(XVmoy/(j-1))))
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Chacun est libre de penser ce qu'il veut. Mais des doublons sur un index unique je trouve cela très grave. Imagine, qu'un injecteur de Morphine piloter par une base qui fait des doublons sur une clé unique, le type va bien roupiller.
Mais pour l'instant tu n'as toujours pas répondu à la liste des 2 dysfonctionnements que je t'ai signalé en bottant en touche. "En disant que tu n'allais pas réinstaller WD7.5"
Je te cite dans le thread original Adrien a dit :"Je ne cherches pas à te démontrer l'inverse, je suis sûr que tu ne râle pas dans le vide. Je voulais juste tempérer ton message. Il est vrai que je n'ai pas de bug de wd7.5 qui me gêne." C'est normal puisque tu n'as plus WD7.5 d'installer!Non?
Ce n'est pas la peine que tu perdes du temps à faire le test sur WD10, car des internautes sur cette liste ont pris le temps de faire le test.
Et le résultat est le même entre WD7.5 et Windev 10, malheureusement.
Maintenant sur certaines TDF régionales on va peut être improviser une séance questions/réponses histoire de voir où en est l'éditeur? Que penses tu de cet idée? C'est WIN-WIN, pour les clients et l'éditeur.
1 /-Concernant crypte/décrypte je pense que c'est la RFC3548 qui doit être fausse, car depuis la 7.5 le base64 produit est erroné, même en 10-62e!
Concernant la fonction PING1 c'est simplement l'ordre des variables qui est primordial dans leur déclaration. Pourquoi mystère, mais beaucoup de temps de perdu pour trouver la solution.
J'offre cette fonction à la communauté Windev (enfin penser à la corriger, c'est un PING à la Windows, totalement paramétrable)
Pour que la procédure locale PINGD fonctionne croiser les variables "j est entier" avec "XReplyData est un entier sans signe".
PROCEDURE PINGD(pAdresse est une chaîne,pBoucle est entier = 1,pTimeOut est entier %0) j est entier
IP_OPTION_INFORMATION est une structure TTL est un entier sans signe sur 1 octet Tos est un entier sans signe sur 1 octet Flags est un entier sans signe sur 1 octet OptionsSize est un entier sans signe OptionsData est une chaîne fixe sur 128 FIN
IP_ECHO_REPLY est une structure Address est un tableau fixe de 4 entier sur 1 octet sans signe Status est un entier sans signe RoundTripTime est un entier sans signe DataSize est entier sans signe Reserved est un entier sans signe data est un entier sans signe Options est un IP_OPTION_INFORMATION FIN XL_EchoReply est un IP_ECHO_REPLY XL_OptInfo est un IP_OPTION_INFORMATION XIpAdress est un entier sans signe XretVal est un entier XSize est un entier XhIcmp est un entier sans signe Xerror est entier XVmoy est entier XReplyData est un entier sans signe
XSize = Dimension(XL_EchoReply)
XIpAdress = AppelDLL32("Wsock32", "inet_addr", pAdresse) SI XIpAdress = 0xFFFFFFFF ALORS Info("Adresse non conforme") RETOUR FIN
POUR j= 1 A pBoucle XIpAdress = AppelDLL32("Wsock32", "inet_addr", pAdresse) XhIcmp = AppelDLL32("icmp", "IcmpCreateFile") XretVal = AppelDLL32("icmp", "IcmpSendEcho", XhIcmp, XIpAdress,Répète("A",32), 32, Null, &XReplyData, XSize, pTimeOut) Transfert(&XL_EchoReply,&XReplyData,XSize) SELON XL_EchoReply:Status CAS 0 : Trace("Réponse de "+XL_EchoReply:Address[1]+"."+XL_EchoReply:Address[2]+"."+XL_EchoReply:Address[3]+"."+... XL_EchoReply:Address[4]+" : Octets="+XL_EchoReply:DataSize+" temps="+XL_EchoReply:RoundTripTime+" ms"+" Satut :"+Remplace(XL_EchoReply:Status[[1]],0,"Ok")) XVmoy+=XL_EchoReply:RoundTripTime AUTRE CAS : Xerror++ FIN FIN AppelDLL32("icmp", "IcmpCloseHandle", XhIcmp) Info("Succes : "+Val(j-1-Xerror),"Erreur : "+Xerror,"Vitesse Moyenne : "+PartieEntière(Val(XVmoy/(j-1))))
punaise, pendant un moment je croyais que EL c'était Emmanuel Lecoester mais non c'est Elian Lacroix.
Tu peux donner le lien exact de ce que tu cites car des phrases sorties de leur contexte ont rarement du sens.
"Adrien" a écrit dans le message de news:
Salut,
Je trouve que tu fais de la désinformation.
Je viens de relire l'article sur le blog de Elian Lacroix et je trouve qu'il dit le contraire de ce que tu décris :
Daniel >>> On apprend sur son site qu'il y a bien des problèmes, E-L >> Il m'est arrivé sur un site en exploitation d'avoir une erreur de doublon sur cet identifiant automatique.
Daniel >>faute de savoir pourquoi, il est préférable de contourner cet incident avec une solution qu'il propose.... E-L >> Dans pareil cas, une possibilité serait de contourner immédiatement par un traitement forçant l'ajout, urgence d'une programmation tête dans le guidon, code vu aujourd'hui sur un forum. Mais une bien meilleure démarche, consiste à se documenter sur le principe de fonctionnement, afin de connaître les causes possibles.
etc...
A+ Adrien
Daniel a écrit :
Historique Adrien a diffusé une news de titou, concernant les problèmes d'identifiants sur hyperfile, car Titou ne devait pas savoir poster ;-) dans le forum de l'éditeur.
Discussion très intéressante alimentée par Elian Lacroix.
Qui nous fait une grosse théorie sur le comment est géré l'IDautomatique On apprend sur son site qu'il y a bien des problèmes, mais que faute de savoir pourquoi, il est préférable de contourner cet incident avec une solution qu'il propose.
Ma question basique, qui dit Ok maintenant si on travaille avec les transactions il devrait pas y avoir de problème (car les transactions sont bien là pour pallier les défaillances matériels).
Puis, Elian part dans des généralités où ce n'est pas de sa faute mais c'est la faute du voisin. On botte en touche, en essayant de décridibiliser l'intervenant (Manu).
Bref, à priori le sujet est maintenant fermé, donc Titou tu te débrouilles avec tes doublons sur clé unique. Maintenant que tu sais que cela peut exister tu cherches une solution ;-)
Mais attendu que Elian refuse de répondre sur l'aspect transctionnel d'un ensemble d'opération qui devrait éviter cet incident, cela est un manque de transparence flagrant et inquiètant.
Je suis surpris, d'apprendre qu'une clé unique puisse être doublée voire plus sur HyperFile, car même sur une base avec index endommagés sur MySQL en MyISAM, nous avons déjà eu des index endommagés suite à plusieurs coupures de courant (successives) sur le serveur (suite à la foudre), on n'a jamais eu de doublon sur une clé unique (et au pire un refus d'enregistrement, qui nous a rappeler à l'ordre pour faire un contôle des index). Pourtant MyIsam est du fichier indexé, aussi.
punaise, pendant un moment je croyais que EL c'était Emmanuel Lecoester mais
non c'est Elian Lacroix.
Tu peux donner le lien exact de ce que tu cites car des phrases sorties de
leur contexte ont rarement du sens.
"Adrien" <adrien.titou@free.fr> a écrit dans le message de news:
1161631729.798591.43000@b28g2000cwb.googlegroups.com...
Salut,
Je trouve que tu fais de la désinformation.
Je viens de relire l'article sur le blog de Elian Lacroix et je trouve
qu'il dit le contraire de ce que tu décris :
Daniel >>> On apprend sur son site qu'il y a bien des problèmes,
E-L >> Il m'est arrivé sur un site en exploitation d'avoir une erreur
de doublon sur cet identifiant automatique.
Daniel >>faute de savoir pourquoi, il est préférable de contourner
cet incident avec une
solution qu'il propose....
E-L >> Dans pareil cas, une possibilité serait de contourner
immédiatement par un traitement forçant l'ajout, urgence d'une
programmation tête dans le guidon, code vu aujourd'hui sur un forum.
Mais une bien meilleure démarche, consiste à se documenter sur le
principe de fonctionnement, afin de connaître les causes possibles.
etc...
A+
Adrien
Daniel a écrit :
Historique Adrien a diffusé une news de titou, concernant les problèmes
d'identifiants sur hyperfile, car Titou ne devait pas savoir poster ;-)
dans le forum de l'éditeur.
Discussion très intéressante alimentée par Elian Lacroix.
Qui nous fait une grosse théorie sur le comment est géré l'IDautomatique
On apprend sur son site qu'il y a bien des problèmes, mais que faute de
savoir pourquoi, il est préférable de contourner cet incident avec une
solution qu'il propose.
Ma question basique, qui dit Ok maintenant si on travaille avec les
transactions il devrait pas y avoir de problème (car les transactions
sont bien là pour pallier les défaillances matériels).
Puis, Elian part dans des généralités où ce n'est pas de sa faute mais
c'est la faute du voisin. On botte en touche, en essayant de
décridibiliser l'intervenant (Manu).
Bref, à priori le sujet est maintenant fermé, donc Titou tu te
débrouilles avec tes doublons sur clé unique. Maintenant que tu sais que
cela peut exister tu cherches une solution ;-)
Mais attendu que Elian refuse de répondre sur l'aspect transctionnel
d'un ensemble d'opération qui devrait éviter cet incident, cela est un
manque de transparence flagrant et inquiètant.
Je suis surpris, d'apprendre qu'une clé unique puisse être doublée voire
plus sur HyperFile, car même sur une base avec index endommagés sur
MySQL en MyISAM, nous avons déjà eu des index endommagés suite à
plusieurs coupures de courant (successives) sur le serveur (suite à la
foudre), on n'a jamais eu de doublon sur une clé unique (et au pire un
refus d'enregistrement, qui nous a rappeler à l'ordre pour faire un
contôle des index).
Pourtant MyIsam est du fichier indexé, aussi.
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
punaise, pendant un moment je croyais que EL c'était Emmanuel Lecoester mais non c'est Elian Lacroix.
Tu peux donner le lien exact de ce que tu cites car des phrases sorties de leur contexte ont rarement du sens.
"Adrien" a écrit dans le message de news:
Salut,
Je trouve que tu fais de la désinformation.
Je viens de relire l'article sur le blog de Elian Lacroix et je trouve qu'il dit le contraire de ce que tu décris :
Daniel >>> On apprend sur son site qu'il y a bien des problèmes, E-L >> Il m'est arrivé sur un site en exploitation d'avoir une erreur de doublon sur cet identifiant automatique.
Daniel >>faute de savoir pourquoi, il est préférable de contourner cet incident avec une solution qu'il propose.... E-L >> Dans pareil cas, une possibilité serait de contourner immédiatement par un traitement forçant l'ajout, urgence d'une programmation tête dans le guidon, code vu aujourd'hui sur un forum. Mais une bien meilleure démarche, consiste à se documenter sur le principe de fonctionnement, afin de connaître les causes possibles.
etc...
A+ Adrien
Daniel a écrit :
Historique Adrien a diffusé une news de titou, concernant les problèmes d'identifiants sur hyperfile, car Titou ne devait pas savoir poster ;-) dans le forum de l'éditeur.
Discussion très intéressante alimentée par Elian Lacroix.
Qui nous fait une grosse théorie sur le comment est géré l'IDautomatique On apprend sur son site qu'il y a bien des problèmes, mais que faute de savoir pourquoi, il est préférable de contourner cet incident avec une solution qu'il propose.
Ma question basique, qui dit Ok maintenant si on travaille avec les transactions il devrait pas y avoir de problème (car les transactions sont bien là pour pallier les défaillances matériels).
Puis, Elian part dans des généralités où ce n'est pas de sa faute mais c'est la faute du voisin. On botte en touche, en essayant de décridibiliser l'intervenant (Manu).
Bref, à priori le sujet est maintenant fermé, donc Titou tu te débrouilles avec tes doublons sur clé unique. Maintenant que tu sais que cela peut exister tu cherches une solution ;-)
Mais attendu que Elian refuse de répondre sur l'aspect transctionnel d'un ensemble d'opération qui devrait éviter cet incident, cela est un manque de transparence flagrant et inquiètant.
Je suis surpris, d'apprendre qu'une clé unique puisse être doublée voire plus sur HyperFile, car même sur une base avec index endommagés sur MySQL en MyISAM, nous avons déjà eu des index endommagés suite à plusieurs coupures de courant (successives) sur le serveur (suite à la foudre), on n'a jamais eu de doublon sur une clé unique (et au pire un refus d'enregistrement, qui nous a rappeler à l'ordre pour faire un contôle des index). Pourtant MyIsam est du fichier indexé, aussi.