Bonjour à tous,
 
J'ai un problème avec le code suivant:
 

 
Il n'y a pas de problème s'il n'y a pas beaucoup de lignes à enregistrer dans le foreach, mais s'il y en a beaucoup, tout ne s'enregistre pas dans ma base.
Je pense donc que la redirection s'effectue avant que la boucle ne soit finie.
 
Pensez-vous que le problème puisse bien venir de là? Mon header est mal placé?
Auriez-vous une solution pour moi svp?
 
Merci d'avance!

Salut à toi.
j'ai repris ton code, l'ai remit à ma sauce + concaténation. ci-dessous

 
Un petit test que tu peux faire :  
 

 
Je ne suis pas un pro, mais les var_dump, il y a que ça de vrai

Merci à toi lesprate.
 
AU SECOURS! Quelle horreur...
En fait, ce n'est pas une histoire de redirection. Tout va bien de ce côté-là. Je dirais même que c'est plus grave...
 
Le souci est qu'en testant avec var_dump, je me rends compte que le nombre d'enregistrement se limite toujours à 90!!!!  
 
Pourquoi???
 
Merci pour votre aide...

Je m'y perds...
J'ai mal analysé le var_dump...
En effet, il m'indique (grâce à lesprate ) que il n'y a pas de souci au niveau sql ni de la boucle... car si j'ai 200 enregistrements, mon $nb_val est limité lui aussi à 90 enregistrements. La suite est logique, les 90 enregistrements sont bien enregistrés.
Le souci est donc ailleurs et avant la boucle !
 
Il faut savoir que mon formulaire est créé au fur à mesure qu'un article est sélectionné dans une liste (tout ça en javascript). Donc la liste s'allonge au fur et à mesure jusqu'à l'envoi. Et apparemment, au moment de l'envoi, il n'y a que 90 enregistrements qui passent.
 
Pourquoi??? Et surtout, comment y remédier?  
 
Merci

Ton appli ne serait-elle pas hébergée sur un serveur mutualisé ?
 
Moi, j'ai eu le soucis chez OVH : au bout d'un certain nb de requêtes SQL, OVH coupait la connexion à la BD et mon script PHP continuait tranquillement mais forcément, sans accès à la BD, le reste du traitement se passait mal La raison était que c'était pour se protéger du flood SQL.
Regarde si t'aurais pas un msg d'erreur de la part de ton SGBD (MySql, j'imagine ?).

Non j'ai mon propre serveur dédié.
Y aurait-il des réglages à modifier?
 
Mais apparemment, c'est exactement le même problème que toi!
Ouf, une explication c'est déjà ça...
Pourtant 200 lignes, ce n'est quand même pas énorme...
 
Cela dit, si la connexion était coupée, Est-ce que $nb_val ne serait quand même pas lui, à 200?
 
Je vais regarder si je trouve des messages d'erreur...

Fais un print_r($_POST['id_produit_']) pour voir si ton formulaire est bien complet. Ca pourrait venir aussi d'une limitation de la taille de données postée par le navigateur.

Merci pour ton aide rufo.
Le problème est bien là. Dans tous les cas, je n'ai que 90 valeurs!!!
C'est donc le navigateur qui pose problème?
J'utilisais IE. Y a-t-il moyen de contourner ce problème?
 
Merci d'avance

Même problème avec Mozilla
 
Au secours...

Ton formulaire semble trop gros. T'aurais pas la possibilité de poster ton formulaire ligne par ligne avec du Ajax par ex ?

Ouch. Voilà la mauvaise nouvelle de l'année.
Ben si, mais je dois tout recoder. quelle horreur.
En fait, je construisais tout le formulaire en javascript avant de l'envoyer. Et quand le formulaire devient trop gros, ben voilà le résultat.
Je n'ai pas d'autre choix??

Un formulaire avec 200 lignes, ça fait quand même beaucoup, non
Ajax ou découpage en lots de x enregistrements.
 
Voir quand même si t'as pas un pb de conception...

200 lignes c'est très rare, mais c'est arrivé, donc pas le choix...
Allez, c'est parti.
Je vais recommencé en ajax. Voyons le bon côté, j'en retirerai encore d'autres avantages.
Merci beaucoup rufo! Rassuré de voir au moins d'où vient le problème.

Salut,
débrider Apache n'est peut-être pas une solution pérenne, mais vois si ce genre de réglage peut t'aider : http://stackoverflow.com/questions [...] -variables
 
Vu que t'es sur un dédié. Faut bien relancer Apache ensuite.

C'est magnifique NewsletTux. Tu me fais gagner des dizaines d'heures de travail. Il fallait le savoir! 1000 mercis!!!