Problème load data infile

Réduire
X
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • Minie
    a répondu
    Bonjour,

    après moultes tests ... toujours en echec, mais avec quelques précisions.

    Je suis en dédié, et le local est activé

    Mes tests :

    1. Suppression du "LOCAL" dans la requete sql -> erreur accès denied (normal)
    2. Essai du script hors framework totalement indépendant avec sa propre connexion bdd -> aucune erreur, mais aucune execution SQL
    2.1 Tests avec echo de l'execution de la boucle, du chemin de fichier (encore) -> le dossier est bien lu, le fichier est bien trouvé, mais la requete ne s’exécute pas
    2.2 Test sans le "LOCAL" dans script externe -> pas d'erreur accès denied (pas normal car l'utilisateur n'a pas tous les privilèges)

    Voilà j'en suis là et je n'ai toujours pas réussi à refaire fonctionner ce **** de script qui fonctionnait très bien pendant des mois ...


    lefabdu51

    Le fichier error.php n'est pas le souci, il ne faisait que masquer le souci

    Laisser un commentaire:


  • lefabdu51
    a répondu
    ok merci je le cherchais.
    PS, le modele du fichier error.php indique que ce fichier est le fichier systeme (templates/system/error.php).
    Donc soit ton fichier est manquant, soit il est corrompu.

    Seconde question, c est un hebergement mutualisé ou dédié?
    Si ca se trouves c est l hebergeur qui a directement désactivé l'import local dans la config, ce qui te provoques l erreur.

    Laisser un commentaire:


  • roland_d_alsace
    a répondu
    Envoyé par lefabdu51 Voir le message
    il est ou le " de fin il n y a que le debut.....
    Ce n'est pas le début mais la fin qui encadre le chemin et le nom du fichier.
    Le premier étant avant dans la requête SQL : "components/com_....

    Laisser un commentaire:


  • lefabdu51
    a répondu
    '.$fichier.'"
    il est ou le " de fin il n y a que le debut.....

    Laisser un commentaire:


  • Minie
    a répondu
    Oui exact, j'avais oublié, c'est moi qui rapporte le fichier error.php de joomla pour le référencement...

    Et oui, l'erreur n'a rien à voir avec le fichier error qui ne faisait que masquer la vraie qui ne m'inspire pas plus, l'erreur 0 ! Dans mon précédent post.

    A quoi peu bien servir une erreur 0 ?

    Laisser un commentaire:


  • ced1870
    a répondu
    le fichier que tu m'as envoyé ne correspond pas à celui généré par template creator
    comme l'a suggéré Roland, je pense que le fichier error.php n'a rien à voir avec le souci initial

    Laisser un commentaire:


  • roland_d_alsace
    a répondu
    OK, j'avais pas noté que le error.php était généré par templatecreatorCK, d'où la réponse de Ced.

    Concernant ton problème vu qu'il s'agit d'une extension spécifique et d'une requête sur fichier spécifique, je ne vois pas comment on pourrait t'aider.

    La seule chose que tu puisses faire à mon avis, c'est de basculer le site sur un serveur local, et de passer sous x-debug, pour suivre le code pas à pas et voir pourquoi la requête ne s’exécute pas.
    Sinon pour faire une telle opération tu peux t’affranchir du Framework de Joomla, et faire un script php pur lancé par cron (histoire de voir si cela vient du Framework).

    Laisser un commentaire:


  • Minie
    a répondu
    Merci pour vos réponses

    ced1870

    Voici l'erreur que j'obtiens sans le fichier error.php :
    Je t'envoie le fichier par email, je ne l'ai pas modifié c'est l'original de ton extension template CK
    Cliquez sur l'image pour l'afficher en taille normale  Nom : screen0.jpg* Affichages : 0* Taille : 36,3 Ko* ID : 2000759

    roland_d_alsace

    La requête fonctionne dans mysql en mode console ?

    Et sous phpmyadmin tu confirmes bien qu'elle fonctionne aussi (sur le même serveur que ton script) ?
    La requête fonctionne nickel direct en SQL oui, bien sur je change le #_ et le chemin en absolu au lieu de relatif. Elle fonctionnait aussi dans mon script pendant des mois, pourtant je n'ai rien changé.

    Rien de plus dans les logs serveurs, joomla, ou mysql

    Oui justement j'ai fait un echo pour la variable $fichier, tout est bon, j'ai même remplacé par le nom du fichier en dur, changé le chemin en absolu, etc .. J'ai tout passé en revue même si ma requête a fonctionné nickel pendant des mois tous les jours.
    Dernière édition par Minie à 17/05/2019, 09h46

    Laisser un commentaire:


  • roland_d_alsace
    a répondu
    Minie Autre question :

    Il fonctionne ton :
    Code PHP:
    echo $query; ! 
    Tu es sûr à 1000% du contenu de $fichier ?
    Dernière édition par roland_d_alsace à 15/05/2019, 20h28

    Laisser un commentaire:


  • roland_d_alsace
    a répondu
    Envoyé par ced1870 Voir le message
    Salut
    enlève le fichier "error.php" du template (en le renommant par exemple), et regarde si ça remarche
    Envoie moi le fichier error.php par email pour que j'y jette un oeil
    CEd
    ced1870
    Hello Ced.

    Je pense que le message d'erreur et donc le problème du error.php n'a rien à voir avec le problème du script.
    Il apparait juste parce que le script génère une erreur qui abouti à l'appel du error.php du template.

    Enfin c'est mon avis, suite à cette réponse :
    Envoyé par Minie Voir le message
    Bien sur aucun souci pour le chargement de JFactory, j'ai parlé de cet oubli de temps en temps pour faire la relation entre l'erreur ligne 34 et le type de cause.
    ...
    Donc l'erreur apparait à chaque appel du error.php

    Il ne devrait donc pas y avoir de rapport direct, mais cela reste à vérifier.

    Le plus simple serait de tracer le code sous x-debug (c'est ce que je ferais pour avancer).

    Minie : as-tu regardé s'il n'y avait pas + d'info dans les logs de Joomla et dans les logs de mysql, car l'erreur de la page d'erreur du template, doit masquer l'erreur du script, erreur pour laquelle cette page d'erreur est affichée justement.
    Dernière édition par roland_d_alsace à 15/05/2019, 20h31

    Laisser un commentaire:


  • roland_d_alsace
    a répondu
    Envoyé par Minie Voir le message
    ...la requête load data fonctionne nickel dans my SQL, donc pour le script, le problème c'est la requête, sauf que la requête est bonne.
    La requête fonctionne dans mysql en mode console ?

    Et sous phpmyadmin tu confirmes bien qu'elle fonctionne aussi (sur le même serveur que ton script) ?

    Laisser un commentaire:


  • ced1870
    a répondu
    Salut
    enlève le fichier "error.php" du template (en le renommant par exemple), et regarde si ça remarche
    Envoie moi le fichier error.php par email pour que j'y jette un oeil
    CEd

    Laisser un commentaire:


  • Minie
    a répondu
    Bien sur aucun souci pour le chargement de JFactory, j'ai parlé de cet oubli de temps en temps pour faire la relation entre l'erreur ligne 34 et le type de cause.

    Pour ce qui est des conflits de variables, ce n'est pas ca, le script fonctionne si je remplace la requête de load data par un select ou autre requête bidon, par contre, la requête load data fonctionne nickel dans my SQL, donc pour le script, le problème c'est la requête, sauf que la requête est bonne.

    Sans compter que ce script a fonctionné pendant des mois sans souci, du jour au lendemain, est arrivé l'erreur, peut être avec une maj joomla, rien ne me vient à l'esprit.

    Laisser un commentaire:


  • roland_d_alsace
    a répondu
    Envoyé par Minie Voir le message
    Bonjour,

    ... c'est cette erreur (ligne 34) que j'ai à chaque fois que je fais appel à la bdd et que j'oublie le JFactory::getDBO() avant ma requête....
    Il est sûr qu'avant d'utiliser une méthode d'une classe, il faut instancier la dite classe.

    Dont si tu oublies le
    Code PHP:
    $db JFactory::getDBO(); 
    ni la méthode setQuery, ni la méthode execute ne pourront fonctionner.

    Normalement la classe JFactory est chargée dynamiquement par le framework (au moins jusqu'à Joomla 5).

    Mais tu peux toujours rajouter un :
    Code PHP:
    use Joomla\CMS\Factory as JFactory
    Au début de ton code.
    Voir https://ordi-genie.com/joomla/develo...partir-de-j3-8

    Mais je ne comprend pas le rapport entre l'erreur du fichier error.php et ton script.
    Je ne pense pas que la non exécution de ta requete soit liée.

    Pour plus de prudence, vu que tu ne connais pas l'environnement d’exécution du script (appelé dans un plugin de contenu), je n'utiliserai pas des noms de variables aussi génériques, ceci pour éviter toute interaction et de + j'effacerai toute mes variables après usage.

    Donc plutôt un truc dans ce genre :
    Code PHP:
    $XYX123456db JFactory::getDBO();
    $XYX123456query '...';

    echo 
    $XYX123456query;

    $XYX123456db->setQuery($XYX123456query);
    $XYX123456db->execute();

    unset 
    $XYX123456query;
    unset 
    $XYX123456db
    Mais en CLI tu ne devrais pas avoir de problème, vu que tu maitrise tout le code.
    Dernière édition par roland_d_alsace à 15/05/2019, 13h29

    Laisser un commentaire:


  • Minie
    a répondu
    Bonjour,

    merci pour les infos sur les CLI, je ferais mes taches cron comme ca maintenant en effet c'est bien mieux

    Par contre, ca ne fonctionne toujours pas Le script se lance bien, pas de retour d'erreur, mais les données du fichier présent sur le serveur ne sont pas chargées dans la Bdd.

    Sauf que maintenant je n'ai plus de piste puisque plus de message d'erreur.
    (Je précise à nouveau que la requête est bonne, le fichier est valide, le chemin aussi, etc ... puisque je le fait manuellement et que ca fonctionnait avant.)

    En ce qui concerne l'erreur que j'avais dans mon fichier error.php, c'est cette erreur (ligne 34) que j'ai à chaque fois que je fais appel à la bdd et que j'oublie le JFactory::getDBO() avant ma requête. C'est du coup toujours la seule piste que j'ai, si j'arrive à refaire fonctionner ma requête dans mon article, elle fonctionnera aussi dans le fichier CLI, j'en reviens donc à ma piste principale

    Laisser un commentaire:

Annonce

Réduire
1 sur 2 < >

C'est [Réglé] et on n'en parle plus ?

A quoi ça sert ?
La mention [Réglé] permet aux visiteurs d'identifier rapidement les messages qui ont trouvé une solution.

Merci donc d'utiliser cette fonctionnalité afin de faciliter la navigation et la recherche d'informations de tous sur le forum.

Si vous deviez oublier de porter cette mention, nous nous permettrons de le faire à votre place... mais seulement une fois
Comment ajouter la mention [Réglé] à votre discussion ?
1 - Aller sur votre discussion et éditer votre premier message :


2 - Cliquer sur la liste déroulante Préfixe.

3 - Choisir le préfixe [Réglé].


4 - Et voilà… votre discussion est désormais identifiée comme réglée.

2 sur 2 < >

Assistance au forum - Outil de publication d'infos de votre site

Compatibilité: PHP 4.1,PHP4, 5, 6DEV MySQL 3.2 - 5.5 MySQLi from 4.1 ( @ >=PHP 4.4.9)

Support Version de Joomla! : | J!3.0 | J!2.5.xx | J!1.7.xx | J!1.6.xx | J1.5.xx | J!1.0.xx |

Version française (FR) D'autres versions sont disponibles depuis la version originale de FPA

UTILISER À VOS PROPRES RISQUES :
L'exactitude et l'exhaustivité de ce script ainsi que la documentation ne sont pas garanties et aucune responsabilité ne sera acceptée pour tout dommage, questions ou confusion provoquée par l'utilisation de ce script.

Problèmes connus :
FPA n'est actuellement pas compatible avec des sites Joomla qui ont eu leur fichier configuration.php déplacé en dehors du répertoire public_html.

Installation :

1. Téléchargez l'archive souhaitée : http://afuj.github.io/FPA/

Archive zip : https://github.com/AFUJ/FPA/zipball/master

2. Décompressez le fichier de package téléchargé sur votre propre ordinateur (à l'aide de WinZip ou d'un outil de décompression natif).

3. Lisez le fichier LISEZMOI inclus pour toutes les notes de versions spécifiques.

4. LIRE le fichier de documentation inclus pour obtenir des instructions d'utilisation détaillées.

5. Téléchargez le script fpa-fr.php à la racine de votre site Joomla!. C'est l'endroit que vous avez installé Joomla et ce n'est pas la racine principale de votre serveur. Voir les exemples ci-dessous.

6. Exécutez le script via votre navigateur en tapant: http:// www. votresite .com/ fpa-fr.php
et remplacer www. votresite .com par votre nom de domaine


Exemples:
Joomla! est installé dans votre répertoire web et vous avez installé la version française du fichier FPA:
Télécharger le script fpa-fr.php dans: /public_html/
Pour executer le script: http://www..com/fpa-fr.php

Joomla! est installé dans un sous-répertoire nommé "cms" et vous avez installé la version française du fichier FPA:
Télécharger le script fpa-fr.php dans: /public_html/cms/
Pour executer le script: http://www..com/cms/fpa-fr.php

En raison de la nature très sensible de l'information affichée par le script FPA, il doit être retiré immédiatement du serveur après son utilisation.

Pour supprimer le script de votre site, utilisez le lien de script de suppression fourni en haut de la page du script. Si le lien de suppression échoue pour supprimer le script, utilisez votre programme FTP pour le supprimer manuellement ou changer le nom une fois que le script a généré les données du site et le message publié sur le forum. Si le script est toujours présent sur le site, il peut être utilisé pour recueillir suffisamment d'informations pour pirater votre site. Le retrait du script empêche des étrangers de l'utiliser pour jeter un oeil à la façon dont votre site est structuré et de détecter les défauts qui peuvent être utilisé à vos dépends.
Voir plus
Voir moins

Partenaire de l'association

Réduire

Hébergeur Web PlanetHoster
Travaille ...
X