doublon a chaque INSERT - SQL/NoSQL - Programmation
Marsh Posté le 04-11-2006 à 16:48:16
quelles peuvent etre les causes en general de la creation de doublon lors de l'execution d'une requette ?
Marsh Posté le 04-11-2006 à 17:10:04
un fichier .php appelé en tant qu'action lorsqu'un formulaire est validé
Marsh Posté le 04-11-2006 à 17:12:17
Je me suis dit que peut être quand tu inclus index.php ca relance la requete ...
Marsh Posté le 04-11-2006 à 17:19:47
ok je vais tester ça, a la limite si je clos la connexion avant le include la requette devrais etre evité
Marsh Posté le 04-11-2006 à 17:43:56
même pas
c'est vraiment bisard surtout que c'est pas mon 1er fichier qui fait des insert ds une bdd
Marsh Posté le 04-11-2006 à 17:47:38
On peut avoir les sources complete stp ?
Parce que le bout de code n'est certainement pas en cause
Marsh Posté le 04-11-2006 à 18:46:27
Formulaire
Code :
|
J'ai assez simplifié, puisque c'est assez long, il y a un code javascript qui verifie les elements du formulaire, et qui est assez complexe puisqu'il permet l'insertion de BBcode en cliquant sur des boutons pour le textarea
Puis la page php executé au submit
Code :
|
Marsh Posté le 04-11-2006 à 19:59:25
tu utilises IE je suppose ...
et avec firefox ca insert deux fois aussi ?
Marsh Posté le 04-11-2006 à 21:42:36
le formulaire n'est pas en index, mais dans une autre page
une fois le formulaire envoyé, je demande le retour a la page principale
oui j'utilise IE, je vais essayer avec FF
mais bisarement c'est le seul formulaire qui me fait ça
Marsh Posté le 05-11-2006 à 10:40:05
en effet avec FF pas de boublon
il peut venir d'ou le probleme ?
puisque c'est pas la 1ere fois que je fais un insert, et les autres fonctionnent impec avec IE
Marsh Posté le 05-11-2006 à 12:45:17
le probleme viens de ton code html qui est foireux...
et ie, lors du parsing, demande deux fois la page ...
http://bugs.php.net/bug.php?id=10599
Marsh Posté le 05-11-2006 à 14:07:57
le lien est HS mais je vais essayer de trouver un truc similaire
Marsh Posté le 05-11-2006 à 18:23:09
rien a faire, sur ce lien il indique un probleme causé par un BGCOLOR au millieu de la table
j'ai justement un BG color au milieu de ma table, mais même retiré le probleme persiste !
c'est vraiment penible !
je me suis aussi rendu compte qu'en faisant F5 une fois la page principale retournée, ça executait le script, puisqu'il reste en barre d'adresse
Vous avez une idée pour eviter ce genre de probleme ? initialiser une variable en session depuis la page du formulaire par exemple
Marsh Posté le 05-11-2006 à 18:29:32
En fait je viens de me rendre compte que ça fait ça pour tous mes formulaires, IE les envois 2 fois
je vais faire champ caché qui se vide une fois la requette effectuée
Ai je le droit de faire ça -> $_POST['truc'] = 0; ??????
y a pas d'autres solution que de passer par les sessions ?
je ne sais même pas ce qui est executé 2 fois, si c'est le formulaire, le fichier de reception, ou les 2 !
c'est le basard ce truc
Marsh Posté le 05-11-2006 à 18:53:29
ca viens de ton <body> non ?
et pour éviter ca, faut faire une page de transition (comme sur le forum)
Marsh Posté le 05-11-2006 à 19:05:56
ouai c'est ce que je suis en train de me dire ! puisque quand je fais un include pour aller sur la page d'accueil, la page des requettes sql reste en barre d'adresse, donc doit surement se reexecuter !
Marsh Posté le 05-11-2006 à 19:26:11
bon bah même la redirection n'empeche pas le doublon
ça commence a me gonfler
et sur un autre formulaire j'ai un doublon une fois sur 3
Marsh Posté le 06-11-2006 à 02:38:19
KangOl a écrit : ca viens de ton <body> non ? |
Si tu fais 2 retours en arrière c'est le même pb
Y'a qu'une solution à ça, le traiter toi même et vérifier que tu veux pas envoyer 2 fois de suite la même chose
Mais apparement Fazer a quand même plein de soucis purement conceptuels, et j'ai l'impression qu'il est dans une grosse mouise d'usine à gaz ingérable
Marsh Posté le 06-11-2006 à 17:23:41
pkoi conceptuels ?
j'ai fais les choses dans l'ordre, et tres proprement, j'ai un code assez complexe
un formulaire, du js qui analyse sur place, puis du php une fois submité pour analyser le formulaire
c'est sufisament bien construit non ?
Marsh Posté le 07-11-2006 à 03:19:15
Sauf que tu pars déjà dans des histoires de redirection (à moins que ça soit juste un problème de compréhension de ma part ), tout est mélangé visiblement et la preuve t'arrives même pas à savoir ce qu'il faudrait faire pour ton histoire de formulaire
Le js on s'en cogne royal, c'est gadget ni plus ni moins Après que tu vérifies les données c'est une bonne chose mais c'est surtout normal.
Prends une feuille de papier, réfléchie à ce que tu veux au final et regarde ce qui est commun, comment t'y parviens dans un cheminement logique et vois comment décomposer la chose de manière élémentaire
PS: ce que tu considères dans l'ordre ne l'est pas forcément, et justement parfois faut pas uniquement voir l'ordre (1,2,3,4,5...) mais le modèle.
Marsh Posté le 07-11-2006 à 09:06:26
Pour la redirection, c'est parce que j'utilise des pseudo frame sur tout le site, sauf pour le fichier d'enregistrement du formulaire, car j'avais qqes problemes. Donc quand je quittais la page d'enregistrement pour retourner a l'accueil, sans faire de redirection j'avais l'adresse de la page qui persistait dans la barre d'adresse. Mais je commence a comprendre pourquoi tu te poses des questions ça se sujet, je vais reessayer avec la pseudo frame
et justement, je me posais une question pour la page de transition, comment cela doit se passer ?
- formulaire submité qui envoie les info à une page php qui elle fait les requette sql, une fois les requettes effectuées elle lance la page de transition qui dure 5 secondes, puis retourne a l'accueil,
- ou bien formulaire qui envoie les infos a la page de transition qui dure 5 secondes, qui elle même analyse le formulaire, puis retourne en page d'accuel ?
en gros la page de transition c'est elle qui doit analyser les données ou non ?
Marsh Posté le 07-11-2006 à 09:28:05
tu as plusieurs façon de faire. La plus simple étant de faire une page de traitement, que ton formulaire va appeler, et de cette page de traitement repartir sur , soit ta page d'accueil si ton formulaire était bien remplis, soit sur ton formulaire sinon.
dans cette page de traitement, tu retrouve les appels aux fonctions de vérifications de ton formulaire, les appels à la base de données si besoin, et la redirection ( header(accueil.php)) vers la bonne page.
Aprés tu peux aussi faire une page de traitement générique, mais ça implique que tu ais prévus ça dans le codage de tes formulaires.
Marsh Posté le 07-11-2006 à 09:40:12
jusqu'a present, j'avais fait le formulaire qui envoie a une page de traitement, qui envoie vers une page de transition ( header( ) ), qui celle ci affiche un message, puis qui redirige 5s plus tard vers l'accueil
donc j'ai le droit
pour la page de traitement generique je prefere eviter, ça risque de compliquer encore plus
en cas d'erreur dans la page de traitement, quelle commande utiliser pour retourner sur la formulaire ? du document.location.href de js ?
Marsh Posté le 07-11-2006 à 09:48:26
nan tu redirige avec un header, mais avant tu set une variable de session avec ton post...
Marsh Posté le 07-11-2006 à 16:06:50
Fazer916 a écrit : Pour la redirection, c'est parce que j'utilise des pseudo frame sur tout le site, sauf pour le fichier d'enregistrement du formulaire, car j'avais qqes problemes. Donc quand je quittais la page d'enregistrement pour retourner a l'accueil, sans faire de redirection j'avais l'adresse de la page qui persistait dans la barre d'adresse. Mais je commence a comprendre pourquoi tu te poses des questions ça se sujet, je vais reessayer avec la pseudo frame |
Justement si tu utilises un controleur centralisé pourquoi faire une page d'enregistrement à part
Marsh Posté le 04-11-2006 à 15:08:21
voici mon code
mais je me retrouve avec un doublon dans ma table a chaque fois, d'ou peut venir le probleme ?
Message édité par Fazer916 le 04-11-2006 à 15:09:11