lokiiy Posted February 19, 2013 Share Posted February 19, 2013 (edited) Je me retrouve confronté a une erreur SQL qui met donné grâce a l 'activation TRUE dans le fichier config.inc.php Le problème c'est que je ne sais pas lire ce genre d'erreur pour la corriger. Je voudrais savoir si quelqu'un ici aurait une piste pour m'aider à mieux comprendre et à chercher l'erreur pour la corriger... Voici l'erreur ci dessous qui s'affiche dans une page blanche Column 'id_product' in field list is ambiguous SELECT id_product, on_sale FROM `ps_product` p, `ps_specific_price` sp WHERE p.`id_product` = sp.`id_product` AND sp.`to` < "2013-02-19 23:37:05" AND sp.`reduction` <> 0 AND id_product NOT IN (SELECT id_venteflash FROM `ps_dompromo` WHERE datefin > "2013-02-19 23:37:05") Et au passage puisque je suis un "NOOB" quel est la différence entre lactivation de @ini_set('display_errors', 'off'); sur on ou off ... et define('PS_DEBUG_SQL', true); sur true ou false... ( pour ici j'ai compris que çà me montré un soucis sql mais si je le laisse activer je comprend aussi que l’accès a ma boutique est inaccessible) Merci d'avance pour vos réponses Edited February 19, 2013 by lokiiy (see edit history) Link to comment Share on other sites More sharing options...
J. Danse Posted February 19, 2013 Share Posted February 19, 2013 L'erreur survient parce que la requête SQL mentionne la colonne id_product (dernière ligne, au niveau du AND). Cependant, deux tables sont impliquées dans la requête: ps_product et ps_specific_price. Celles-ci contiennent toutes les deux une colonne id_product. Lors du traitement, on ne sait donc pas à quelle colonne on fait référence. Un exemple avec Excel: deux feuilles du même catalogues ont une colonne A1. Si on mentionne Feuille1.A1 ou Feuille2.A1, on sait à quelle feuille fait référence A1. Seulement, si on indique simplement A1, quelle feuille est demandée ? Le display_errors affiche les erreurs PHP, le DEBUG_SQL affiche les erreurs dans les requêtes. C'est donc deux choses différentes. Link to comment Share on other sites More sharing options...
lokiiy Posted February 20, 2013 Author Share Posted February 20, 2013 Merci de la réponse.... Cependant cela m'indique tjrs pas ou chercher ? Vue que c'est des erreur SQL il faut que je cherche dans phpMyAdmin? Mais comment faire pour identifier ses requetes qui posent probleme ? Est ce grave de laisser ainsi ? Le problème provient t'il du module ps_dompromo ?? Merci de votre attention Beaucoup de questions je sais !! mais j'aime comprendre Link to comment Share on other sites More sharing options...
manouille Posted February 20, 2013 Share Posted February 20, 2013 (edited) A priori c'est une requête sur la table dompromo donc oui je dirait que c'est ce module qui est impacté. Essaye de réecrire la dernière ligne de la requête dans le fichier php du module. AND p.id_product NOT IN (SELECT id_venteflash FROM `ps_dompromo`) Ajoute le p devant id_product. Au passage une super requête sans index qui doit te bouffer de la ressource. Le NOT IN select c'est quand même hard Edited February 20, 2013 by manouille (see edit history) Link to comment Share on other sites More sharing options...
lokiiy Posted February 21, 2013 Author Share Posted February 21, 2013 Merci pour ses pistes intéressantes Cependant je maitrise vraiment tres mal le php et le sql j'en comprend que les grandes lignes ^^ Ya un début à tout et je commence justement à vouloir me former plus sérieusement en PHP D'ou mon intéressement à ses problèmes qui apparaissent avec la fonction DEBUG Bon j'ai essayé de rajouter le p devant id_product et sans succès ca change rien ... Au passage une super requête sans index qui doit te bouffer de la ressource. Le NOT IN select c'est quand même hard Le NOT IN select c'est quand même hard que veux tu dire par la ?? Désolé mais je comprend pas encore le language PHP et le SQL ( mais soif d'apprendre ) Sinon voici ce qui se trouve dans dans le fichier dompromo.php // [PS 1.4] Annule les soldes et Promos terminés. private function initializventes() { $query = Db::getInstance()->ExecuteS(' SELECT id_product, on_sale FROM `'._DB_PREFIX_.'product` p, `'._DB_PREFIX_.'specific_price` sp WHERE p.`id_product` = sp.`id_product` AND sp.`to` < "'.(date("Y-m-d H:i:s")).'" AND sp.`reduction` <> 0 AND id_product NOT IN (SELECT id_venteflash FROM `'._DB_PREFIX_.'dompromo` WHERE datefin > "'.date("Y-m-d H:i:s").'") '); Merci de ton soutien J'ai rédigé un message au réalisateur du module si des fois il arrive à trouver une solution Link to comment Share on other sites More sharing options...
lokiiy Posted February 21, 2013 Author Share Posted February 21, 2013 Bon bon bon en allant voir à la source ... J'ai eu une nouvelle version de la 1.1 j'ai mis a jour le fameux module vers la 1.2 est du coup nickel ya plus de soucis Par contre je me demande si il faut laisser define('PS_DEBUG_SQL', true); sur true ou plutôt le laisser en false... Car j'ai pu constater que si il y a une erreur ca bloque tout ^^ Bon au moins ya le mérite d'être prévenu direct d'une erreur ... Cependant @ini_set('display_errors', 'on'); et lui je le laisse sur on c'est pas si gênant que ca et utile également .... Link to comment Share on other sites More sharing options...
manouille Posted February 21, 2013 Share Posted February 21, 2013 Cool si le module à une maj pas besoin de se casser la tête Si tu es en production (boutique ouverte avec des commandes) tu mets "false" et "off". En développement tu laisses "true" et "on" ca te permettra de débugger les erreurs. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now