import bdd

Bonjour,

Oui c'est embêtant ce genre de problèmes. La véritable limite se trouve dans le temps d'exécution de vos scripts PHP (et de celui de phpMyAdmin): 40 secondes. Généralement pour palier ces problèmes de timeout on coupe effectivement sa base en plusieurs parties plus petites.

Le serveur est mutualisé ce qui signifie que tu n'es pas le seul à accéder au serveur sql donc chaque tentative est différente de la précédente et comme il y a la limite d'exécution des applications php, il est tout à fait possible que tu n'arrives pas à insérer 1000 enregistrements (d'autant que ça dépend de la taille des enregistrements...).
Les tests en local ne sont pas du tout comparables même si ta machine est peu puissante. D'ailleurs en local tu as accès à mysql en ligne de commande ce qui facilite l'import de grosses base de données.
J'avais rencontré le même problème que toi à mon arrivée ici et il n'y a pas d'autres solutions que le découpage en petits enregistrements. Ensuite tu peux utiliser des applications php qui vont faire le sale boulot et importer chaque petit enregistrement sans dépasser la limite d'exécution. Je ne me rappelle plus des noms des applications php spécialement conçues pour faire ce travail mais en fouillant un peu sur google tu devrais trouver.

Tu peux essayer différents scripts (il y a pas mal de choix car c'est un problème courant). Je n'avais pas eu toujours les mêmes résultats (mais honnêtement je n'ai pas regardé le source donc je ne peux pas t'en dire plus).
Je ne sais pas à quoi ressemble ton script mais une méthode qui devrait fonctionner :
- 1 script php qui va sauvegarder X enregistrements dans un fichier. La taille du fichier doit être relativement petite et le nombre d'enregistrements petit également. Tu te retrouveras avec un bon nombre de fichiers.
- 1 script php qui va restaurer les fichiers dans la base de donnée. Pour éviter d'atteindre le délai maximal d'exécution, l'astuce est de recharger la page à la fin d'un traitement. De cette façon tu répartis les chargements et donc le délai d'exécution ne peut pas être atteint.
C'est peut être ce que tu as déjà fait. Il me semble que c'était le genre de solution que j'avais utilisé (sauf que dans mon cas les enregistrements étaient eux mêmes trop lourd donc la solution était un peu plus compliquée).
Bon courage.

ok mais si j'ai bien compris, le script lit un seul fichier texte et surtout il le lit en entier.
Donc ça ne résout pas le problème des gros import puisque le temps d'exécution du script va être supérieur au temps alloué par le serveur et dans ce cas là : oui ça dépend du serveur mais il ne faut pas rêver, sur un hébergement mutualisé, tu ne pourras jamais importer un fichier SQL d'une centaine de Mo en une seule fois.
Alors soit je n'ai pas compris ce que tu as dit, soit le script dont tu parles utilise une astuce pour passer au delà de la limitation du temps d'exécution
Enfin revenons en à ton problème, tu as essayé quelles applications php ? (avec un lien vers le site où tu les as trouvé vu que les Dump, bigdump sont légions sur internet).

C'est bien la méthode que je t'ai présenté sauf qu'il utilise un décalage dans le fichier au lieu de découper le fichier en plusieurs fichiers.
Avec ce script ça ne fonctionne pas ?

Bonsoir,

Vous pourriez nous mettre votre fichier import SQL sur votre FTP ? Cela nous permettrait à terme de pouvoir procéder à des tests. Merci

bonjour,
non pas d'erreur 500, mais internal error server port 80.

toad, mon server ftp perso est en route avec le fichier dessus.
je te fais parvenir les donnees.

bonne journee