le coup des trim qui suggère qu'il y a peut être des espaces en trop devant ou derrière...

Le trim ne change rien.

Si tu fais un SELECT * FROM RVRTusers WHERE Userid = 'Hervé-PRD'; obtiens tu une ligne en retour ?

Oui, une.

Pareil avec la table des logs, un SELECT * FROM RVRTlog WHERE Userid = 'Hervé-PRD'; retourne bien des lignes ?

Non, aucune, bizarre parce qu'avec un Browse j'en trouve plusieurs.

Ceci voudrait dire que tous les Hervé-PRD qui sont dans la table log sont différents du Hervé-PRD de la table users.
Mais je ne comprends pas, je vois bien que c'est la même chose !
Le format de la zone Userid des 2 tables est la même.

Et bien il y a donc bien un problème visiblement d'espace en trop (peut être des caractères invisibles). C'est pour cela que dans ton code d'origine tu avais du ajouter des trim() et utiliser le LIKE avec les %. Bref si tu essaies d'éditer une ligne de la table RVRTlog y a-t-il des espaces dans l'input avant ou après ton pseudo ? Si c'est le cas il va falloir que tu corriges l'alimentation de la table. Tu peux aussi faire un petit algo pour nettoyer la colonne, ainsi la requête avec jointure pourra ensuite fonctionner.

Si tu as une table users, pourquoi n'utilise tu pas un id chiffré ? tu éviterait tous ces soucis de comparaison.
Je sais que cela veut dire changer la structure de tes tables et de ton code, mais c'est vraiment plus simple pour les jointures

si tu essaies d'éditer une ligne de la table RVRTlog y a-t-il des espaces dans l'input avant ou après ton pseudo ?

Non
En haut un extrait de la table log, en bas de la table users, avec Userid en cours d'édition

Si tu as une table users, pourquoi n'utilise tu pas un id chiffré ?

Si le userid est différent dans les 2 tables, un userid chiffré le serait aussi.

si tu essaies d'éditer une ligne de la table RVRTlog y a-t-il des espaces dans l'input avant ou après ton pseudo ?

Non
En haut un extrait de la table log, en bas de la table users, avec Userid en cours d'édition

Si tu as une table users, pourquoi n'utilise tu pas un id chiffré ?

Si le userid est différent dans les 2 tables, un userid chiffré le serait aussi.

Et je rappelle que ma version fonctionne !

Ta version fonctionne oui, mais n'est pas optimalisé et te fais perdre un temps considérable, d'où ta demande.

Ta version fonctionne oui, mais n'est pas optimalisé et te fais perdre un temps considérable, d'où ta demande.

Je préfère quand même une version qui fonctionne lentement qu'une version rapide qui ne fonctionne pas.
Je ne comprends toujours pas pourquoi ceci donne des résultats
SELECT * FROM RVRTusers where Userid = '".$Userid."' order by Dates desc
et ceci aucun
SELECT rlog.Userid as 'Userid',DATE_FORMAT(rlog.Timestamp , '%d/%m/%Y') as 'date_jour',
DATE_FORMAT(rlog.Timestamp , '%T') as 'heure_jour',rlog.Version,rlog.Module,rusers.Prenom,rusers.Nom,rusers.Email
FROM RVRTlog as rlog
LEFT JOIN RVRTusers as rusers
ON trim(rlog.Userid) = trim(rusers.Userid)
ORDER BY rlog.Timestamp DESC

Si on avais un jeu de données réel, juste ceux avec Hervé, on pourrait déboguer et te proposer une solution.

C'est gentil : comment faire ?

Herve_be,le be il y a un rapport avec la Belgique?

Dans phpmyadmin tu sais faire un export en SQL . D'ailleurs affiche nous les lignes de Hervé, je pense qu'on aura déjà une idée du souci.

Herve_be,le be il y a un rapport avec la Belgique?

Oui, pourquoi ?

Dans phpmyadmin tu sais faire un export en SQL .

Pas de problème pour la table log; pour la table users je devrais masquer les nom, prenom et email.
Et puis comment faire pour te transmettre le fichier ?

affiche nous les lignes de Hervé, je pense qu'on aura déjà une idée du souci.

Tu l'as ci-dessus.

Si le userid est différent dans les 2 tables, un userid chiffré le serait aussi.

Je parlais de remplacer le userid par un chiffre, pas chiffré le texte.

En régle générale lors de la conception d'une structure on évitera des liaison entre tables en varchar
surtout si il y a des accents.

Sais tu essayer de remplacer tous les accents par leur lettre non-accentué ? ou essayer le script sur un userid sans accent.

Parce que si tu es sur Namur,on pourrait s'arranger.
Sinon [email protected]

Sais tu essayer de remplacer tous les accents par leur lettre non-accentué ? ou essayer le script sur un userid sans accent.

La table des userid contient plus de 2000 records : la plupart na pas d'accent.

Parce que si tu es sur Namur,on pourrait s'arranger.

Je suis entre Mons et Ath.
J'ai essayé de "dumper" les tables.
Dans la table log le userid est suivi de \r (carriage return) \n (newline)
('151021', '151023161630', '151023', 'Angles', 'didier19672\r\n')
dans la table users c'est l'email qui est suivi de \r\n
('150112', 'didier19672', 'didier', 'nom', '[email protected]\r\n')
c'est donc au dernier champ que ces caractères sont ajoutés, probablement par le script qui alimente la db
si ces caractères font effectivement partie du champ je comprends qu'il ne le trouve pas
mais je ne comprends alors pas comment il les trouve avec ma version actuelle qui fonctionne.

Ah ben voilà des retours à la ligne ce qui peut être assimilé à un caractère invisible. Si la version actuelle c'est avec le LIKE et les % ça fonctionne car avec le % de la fin tu peux avoir n'importe quoi derrière la chaîne. Si c'est avec le = c'est que tu fais un trim lorsque tu alimentes $Userid et que le trim nettoie entre autre les retours chariot. C'est peut être pas exactement ça mais c'est un truc dans le genre. Dans le cas où ça fonctionne c'est que les traitements opérés et/ou la manière de comparer permettent la reconnaissance.