Bonjour
@bsizorn est-ce que toutes tes tables sont en utf8_general_ci ?
Fred
Bonsoir Fred,
oui, toute la BDD est en utf8_general_ci .
Voici la capture pour la table llx_accountingaccount
Merci
Bonjour
@bsizorn
SELECT f.facnumber, f.rowid AS facid, f.datef, f.type AS ftype, l.fk_product, l.description, l.total_ht, l.rowid, l.fk_code_ventilation, p.rowid AS product_id, p.ref AS product_ref, p.label AS product_label, p.fk_product_type AS
TYPE , p.accountancy_code_sell AS code_sell, p.tva_tx AS tva_tx_prod, aa.rowid AS aarowid, l.product_type AS type_l, l.tva_tx AS tva_tx_line
FROM llx_facture AS f
INNER JOIN llx_facturedet AS l ON f.rowid = l.fk_facture
LEFT JOIN llx_product AS p ON p.rowid = l.fk_product
LEFT JOIN llx_accountingaccount AS aa ON SUBSTR( p.accountancy_code_sell, 1, 3 ) = aa.account_number
LEFT JOIN llx_accounting_system AS accsys ON accsys.pcg_version = aa.fk_pcg_version
WHERE f.fk_statut >0
AND fk_code_ventilation <=0
AND (
accsys.rowid = ‹ 2 ›
OR p.accountancy_code_sell IS NULL
OR p.accountancy_code_sell = ‹ ›
)
ORDER BY f.datef DESC , f.facnumber DESC , l.rowid DESC
LIMIT 26
Fred
Bonjour Fred,
même résultat … Aucune ligne
Bonne journée
Bruno
Bonjour @asparango.
non, ni l’un ni l’autre. C’est une version de base de Dolibarr, sans aucun module de Dolistore, juste la comptabilitéExpert d’activée.
Bruno
@asparango et Fred,
faites une pause, j’ai un doute sur un truc, Je vérifie tout ça et je reviens vers vous
A plus tard
Merci
Me revoilà, avec de nouvelles infos, et j’ai honte :
J’avais fais des essais sur une autre base de données reconfigurée, et j’ai effectué tous les tests que vous m’aviez demandé sur la mauvaise BDD. Je suis vraiment confus. Vraiment, vraiment, toutes mes excuses.
L’erreur est toujours présente évidemment, mais Fred à peut-être mis le doigt sur le problème : effectivement, toute la bdd est en « latin1_swedish_ci »
Je suppose que l’on peut passer toute la base en « utf8_general_ci » avec une seule requête au lieu de le faire table par table, mais je ne trouve pas. Est-ce que vous auriez la requête pour faire le changement sur toute la base ?
Une fois cela changé, si j’ai toujours le soucis, je referais tous les tests demandés par Fred et vous donnerais tous les résultats en une fois (Déjà, après un petit test, pratiquement toutes les requêtes proposées par Fred renvoient un résultat).
Encore merci, et encore toutes mes excuses
Bruno
Bonjour
L’encodage n’est pas gênant si c’est partout pareil. cela peut le devenir si on compare une colonne en utf8 avec une colonne en latin1 pour la performance et l’usage des index. Il vaut mieux ne pas le changer tu risque d’avoir des caractères bizarres si ça se passe mal.
Fred
Ok, je le laisse donc comme ça.
Si je reprends tes requêtes depuis le début (sur la bonne BDD cette fois 
), voici les résultats, il semble que tu sois sur une bonne piste :
Le resultat du EXPLAIN :
La même requete dans phpmyadmin sans le EXPLAIN, renvoie :
"#2013 - Lost connection to MySQL server during query "
La requête suivante que tu avais demandée, renvoyait par contre des enregistrements :
Ta requête suivante renvoie également des enregistrements :
La requete suivante que tu avais soumise donne exactement le même résultat que ci-dessus
SELECT f.facnumber, f.rowid as facid, f.datef, f.type as ftype , l.fk_product, l.description, l.total_ht, l.rowid, l.fk_code_ventilation, l.product_type as type_l, l.tva_tx as tva_tx_line , p.rowid as product_id, p.ref as product_ref, p.label as product_label, p.fk_product_type as type, p.accountancy_code_sell as code_sell, p.tva_tx as tva_tx_prod FROM llx_facture as f INNER JOIN llx_facturedet as l ON f.rowid = l.fk_facture LEFT JOIN llx_product as p ON p.rowid = l.fk_product WHERE f.fk_statut > 0 AND l.fk_code_ventilation <= 0 AND (p.accountancy_code_sell IS NULL OR p.accountancy_code_sell =’’) ORDER BY f.datef DESC,f.facnumber DESC,l.rowid DESC LIMIT 26
Ta requête de ce matin :
SELECT f.facnumber, f.rowid AS facid, f.datef, f.type AS ftype, l.fk_product, l.description, l.total_ht, l.rowid, l.fk_code_ventilation, p.rowid AS product_id, p.ref AS product_ref, p.label AS product_label, p.fk_product_type AS
TYPE , p.accountancy_code_sell AS code_sell, p.tva_tx AS tva_tx_prod, aa.rowid AS aarowid, l.product_type AS type_l, l.tva_tx AS tva_tx_line
FROM llx_facture AS f
INNER JOIN llx_facturedet AS l ON f.rowid = l.fk_facture
LEFT JOIN llx_product AS p ON p.rowid = l.fk_product
LEFT JOIN llx_accountingaccount AS aa ON SUBSTR( p.accountancy_code_sell, 1, 3 ) = aa.account_number
LEFT JOIN llx_accounting_system AS accsys ON accsys.pcg_version = aa.fk_pcg_version
WHERE f.fk_statut >0
AND fk_code_ventilation <=0
AND (
accsys.rowid = ‹ 2 ›
OR p.accountancy_code_sell IS NULL
OR p.accountancy_code_sell = ‹ ›
)
ORDER BY f.datef DESC , f.facnumber DESC , l.rowid DESC
LIMIT 26
Renvoie #2013 - Lost connection to MySQL server during query
Voilà donc tous les tests que tu avais proposé, cette fois sur la bonne base. Il semble que tu n’étais pas loin de la vérité si je n’avais pas fais de conne… et ne t’avais pas fais perdre ton temps inutilement
Bruno
Bonjour
Peux tu ajouter l’index demandé dans les premiers messages et faire la première requête sans EXPLAIN
Fred
Bingo !
Après avoir ajouté l’index sur « account_number », la requête renvoie des résultats et …
La page « ventilation client » s’affiche sans problèmes.
Nous sommes apparemment opposés géographiquement, mais si tu passes par la Bretagne un de ces jours, je t’offres un verre (et même 2 ! ) pour te remercier et m’excuser de ma méprise.
Merci à vous 2
Bonjour
Pas de problème, ça a le mérite de faire avancer le schmilblick et comme ça on sait que l’index est nécessaire.
Fred
Merci pour ton aide Frederic, je vais faire ajouter l’index chez le client dont je t’ai envoyé le dump voir si cela répare le problème.
Bonjour
Selon le nom de la table la requête est:
ALTER TABLE llx_accountingaccount ADD INDEX idx_accountingaccount_account_number (account_number);
ou
ALTER TABLE llx_accounting_account ADD INDEX idx_accounting_account_account_number (account_number);
Il faut aussi voir si dans la table product il y a par exemple 707000 alors que c’est seulement 707 dans accounting_account
d’ou le SUBSTR(…,1,3)
Fred
Oiu, j’ai fait le changement à partir de la version 3.9 sur le nom de la table.
Par contre, le substr ne fonctionnera pas à tous les coup car un compte peut être à 2 voir 6 chiffres et même plus au besoin. Il faudrait surtout que j’écrive une fonction qui supprime tous les zéros en fin de compte (le plan comptable n’en ayant pas) et après à l’affichage et à l’export, la longueur de compte soit fixé selon la configuration actuelle. Je vais revoir ça…
