dimi3 Posté 7 Janvier 2013 Posté 7 Janvier 2013 (modifié) Bonjour, Mon programme doit traiter des gros fichiers textes et passe jusqu'à des milliers de variables en POST. En local, j'ai édité le fichier php.ini : max_execution_time = 0 max_input_time = 0 safe_mode = off En tête de mes fichiers php j'ai codé : set_time_limit(0); Lorsque le fichier est petit, toutes les variables passées en POST passent bien; Lorsque le fichier est gros, les dernières variables passées en POST ne passent pas. Le problème ne vient pas des temps d'exécution mais de variables indéfinies lorsque leur nombre est trop grand. Je ne vois pas quoi faire... Je vous remercie si vous avez une idée. Meilleurs voeux à tous pour la nouvelle année. Modifié 7 Janvier 2013 par dimi3
captain_torche Posté 7 Janvier 2013 Posté 7 Janvier 2013 On parle de combien de variables (Au total / qui passent) ? n'y aurait-il pas une limitation dans le protocole POST même ? T'est-il possible de passer les variables en plusieurs fois ?
dimi3 Posté 7 Janvier 2013 Auteur Posté 7 Janvier 2013 Merci pour votre réponse. Pour certains fichiers, il passe des milliers de variables. Les dernières centaines ne passent pas. Où se code cette limitation dans le protocole POST ? Comment modifier cela ? Passer les variables en plusieurs fois serait en effet une solution. Mais là je ne vois pas trop encore.
SStephane Posté 7 Janvier 2013 Posté 7 Janvier 2013 Tu as post_max_size, et sinon suhosin limite le nombre de variables post s'il ets installé sur ton serveur, il faut modifier dans la conf suhosin si c'est ça (je me rappelle plus du nom mais c'est facile à trouver). ***edit à ajouter dans php.ini suhosin.post.max_vars=10000 suhosin.request.max_vars=10000
dimi3 Posté 7 Janvier 2013 Auteur Posté 7 Janvier 2013 Bonsoir, Une recherche de "suhosin" dans le php.ini ne donne rien (version du php : 5.3.10) J'ai ajouté suhosin.post.max_vars=10000 et suhosin.request.max_vars=10000. Ca n'a pas résolu le problème. J'ai tenté php_value suhosin.post.max_vars 10000 et php_value suhosin.request.max_vars 10000 dans le fichier htaccess : je n'ai pas eu plus de succès.
SStephane Posté 7 Janvier 2013 Posté 7 Janvier 2013 suhosin limite le nombre de variables post s'il ets installé sur ton serveur S'il est pas installé, ces lignes ne servent à rien... Hormis un addon type suhosin, il n'y a rien à ma connaissance qui limite le 'nombre' de variable post livré avec PHP (je ne parle pas de taille, mais de nombre). Vois du côté de la mémoire (memory_limit), ou donne nous un bout de code (et une conf) qui plante, sinon tu risques de jouer à cache cache un moment
dimi3 Posté 8 Janvier 2013 Auteur Posté 8 Janvier 2013 Bonjour et merci, J'avais pensé à memory_limit que j'ai mis à -1 . Mais ça n'a rien donné non plus. Mon code n'a pas de souci du fait que si le fichier est court tout se passe bien. Mon code ne plante pas. La seule erreur signalée est "variable indéfinie" pour les dernières centaines de variables à traiter. Le problème pourrait-il tout simplement venir d'une mémoire physique insuffisante de mon petit portable ?
jcaron Posté 8 Janvier 2013 Posté 8 Janvier 2013 Si je comprends bien (difficile vu le peu de détails), tu as deux scripts: un premier qui lit un fichier et qui fait un POST de plein de variables vers un deuxième qui reçoit ces variables en POST et fait tout plein de choses avec, et dans certains cas ce deuxième script ne reçoit pas tout ce qu'il devrait. C'est ça? Ou alors tu as un premier script qui génère une page HTML avec un formulaire avec tout plein de variables et un POST vers le deuxième script? La première chose à déterminer, c'est de quel côté se situe le problème: est-ce-que c'est le premier script qui n'envoie pas tout, ou est-ce que c'est le deuxième qui ne reçoit pas tout? S'il y a beaucoup de varialbles, je suppose aussi qu'elles sont numérotées d'une façon ou d'une autre, peut-être que tu n'as pas la même convention de part et d'autre? Commence par examiner ce qu'envoie le premier script pour t'assurer qu'il envoie bien tout comme il faudrait. Une fois que c'est fait, tu pourras te concentrer sur le deuxième script. Jacques.
dimi3 Posté 8 Janvier 2013 Auteur Posté 8 Janvier 2013 Le premier fichier récupère les données d'un fichier texte (de type .csv) dans un formulaire. Par une boucle, chaque input est nommé ainsi : echo "<input type = \"text\" name=\"enregistrement".$i."\" value=\"$tab[$i]."\">"; Le second fichier reçoit les variables "enregistrementX" par $_POST["enregistrement".$i] dans une boucle. ------------------ Je remarque que seules les 1000 premières variables sont réceptionnées : 1000 pile-poil, ni plus, ni moins. Et cela, quel que soit le fichier texte mouliné.
captain_torche Posté 8 Janvier 2013 Posté 8 Janvier 2013 C'est donc très probablement une limitation dans la configuration. Tu vas devoir faire plusieurs passes.
dimi3 Posté 8 Janvier 2013 Auteur Posté 8 Janvier 2013 Du fait que je travaille sur mon PC dans wamp, je peux peut-être changer cette limitation ? Je n'ai rien trouvé dans le fichier php.ini. Où chercher encore ?
SStephane Posté 8 Janvier 2013 Posté 8 Janvier 2013 Désactive complétement xdebug s'il est activé, il fixe certaines limites (j'y crois pas beaucoup) Dernier essai sans source pour moi, c'est vraiment trop chiant d'aider sans reproduire.
jcaron Posté 8 Janvier 2013 Posté 8 Janvier 2013 Tu as vérifié le HTML généré? Il contient bien tout ce qu'il faut comme il faut ou pas? Tu n'aurais pas un problème sur le format du "$i" (genre d'un côté ou de l'autre il est formaté sur 3 chiffres et pas un de plus)? Au passage, le $tab[$i] sans encodage, ça va faire des choses pas belles si tu as des " ou des & dans le contenu de ces variables (au moins). Jacques.
captain_torche Posté 8 Janvier 2013 Posté 8 Janvier 2013 Et sinon, tu ne pourrais pas passer par cURL, plutôt que de générer un formulaire et de l'envoyer manuellement ? Parce qu'il est fort probable que tu te heurtes à une limitation navigateur.
dimi3 Posté 8 Janvier 2013 Auteur Posté 8 Janvier 2013 @Stephane la désactivation de xdebug n'a pas résolu le problème @jcaron pas de problème de format imposé pas de guillemets ni & dans le fichier texte @captain_torche le formulaire permet de faire d'éventuelles corrections ou des ajouts dans le fichier texte Qu'entends-tu par cURL ? Tu veux dire par GET ?
captain_torche Posté 8 Janvier 2013 Posté 8 Janvier 2013 Tu veux dire que tu corriges plus de 1 000 champs à la main avant envoi ? Sinon, cURL est une bibliothèque permettant (Entre autres) d'envoyer des données en POST directement en PHP.
dimi3 Posté 8 Janvier 2013 Auteur Posté 8 Janvier 2013 Un programme vérifie les entrées de l'opératrice dans un fichier expédié à un vérificateur. Les erreurs sont signalées. Le formulaire permet de descendre jusqu'à l'enregistrement erroné. Le vérificateur corrige dans le formulaire, et le programme récrit le fichier. Et passer par des variables-sessions ? Cela résoudrait-il le problème ? Ou est-ce encore limité ?
captain_torche Posté 8 Janvier 2013 Posté 8 Janvier 2013 Ne serait-il pas plus simple de n'afficher QUE les données en erreur ? Tu simplifierais énormément les traitements. Pour info, de combien de colonnes disposent les tables de ta base de données ?
dimi3 Posté 8 Janvier 2013 Auteur Posté 8 Janvier 2013 Oui, je vais programmer différemment. Comme tu le suggères, je ne vais afficher que les enregistrements erronées. La base csv compte jusqu'à 37 champs.
dimi3 Posté 8 Janvier 2013 Auteur Posté 8 Janvier 2013 Du nouveau : J'utilisais WampServer. J'ai essayé EasyPHP. Il m'a suffi de changer dans le php.ini la ligne max_input_vars et d'augmenter la limite jusqu'à 15000 pour enfin résoudre le problème qui m'a occupé 2 bonnes journées. Ouf... je n'en peux plus ! Grand merci à tous pour l'intérêt que vous avez porté à mes questions et pour avoir eu souci de m'aider. J'ai appris bien des choses sur le fichier php.ini. Et aussi que WampServer n'est pas fait pour moi...
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant