tout est dans le titre !!!  
 
je n'arrive pas à vérifier lors d'une inscription si le mail existe déjà dans ma base de donnée. Comment pourrais je faire?
 
merci

 
Le genre de question qui tue, mais qui tue...

Suis-je bête : je suis dans la cat PHP.

Salut,
 
plutôt difficile de t'aider sans avoir la structure de ta table...  
 
En gros, en admettant que l'email que tu veuille vérifier sois dans la variable $email,... tu exécute une requête du style :  
 

alter table truc add unique constraint prout on (email);
 
et si quand tu fais insert ça plante, ben c'est que l'email existe déjà
 
simple, rapide, efficace, et charge la plus faible pour le SGBD

Arjuna > A par que s'il s'amuse à mettre une autre colone en unique, il saura pas laquelle a bloqué la requette.

Normalement le message d'erreur est formatté de façon connue, et contient le nom de la contrainte qui a levé l'exception
 
Donc s'il gère correctement l'exception, il doit être capable de savoir ce qui cloche

Plutôt dirty.

Je suis pas sur que ca soit plus propre de devoir analyser un message d'erreur sous forme de texte pour savoir le pourquoi d'une erreur.

Bah si le connecteur à la base possède un meilleur moyen pour renvoyer le détail de l'erreur, why not, mais bon... Moi j'utilise que ADO, et y'a pas à tortiller, c'est du texte

Rien de très compliqué... si par exemple tu récupère la donnée à partir d'un formulaire qui est dans une page précédente, tu met ça :

Et sinon, je vois pas la solution...    
 
P.S: biensûr, il faut que tu rentres les infos de connection MYSQL, mais bon c'est un détail!  

faut un petit limit 1 histoire de pas parcourir toute la table pour rien

Toi tu vas te faire tomber dessus par les anti-injection SQL

le truc c'est que j'ai déjà une vérification pour voir si le pseudo existe déjà, commen cumuler les deux?
 

 
je pesnse que cela doit être à ce niveau, mais je n'y arrive pas.

"SELECT * FROM `Membre` WHERE `pseudo` LIKE '$pseudo' OR email LIKE  $email " ?

Personnellement je serais quand même de l'avis d'Arjuna, le fait qu'un email soit unique sur l'intégralité des enregistrements fait partie des contraintes sur la donnée, et la BDD est parfaitement capable de gérer correctement ce genre de conneries. Pire, c'est son boulot (de manager l'intégrité des données).
 
Je vois pas l'intérêt de rajouter des couches par dessus qui tentent de faire le boulot de la BDD en moins bien, en moins efficace et en moins sûr

Même si on régle les contraintes comme il faut au niveau de la base de donnée (ca, je suis ok à 100%), je ne penses pas qu'il faille se baser sur les retour d'erreur de cette derniére pour savoir quelle contrainte à bloqué.

 
Si c'est elle qui gère l'intégrité de la donnée, c'est elle qui renvoie les erreurs significatives hein, ça me semble quand même logique personnellement

Dans la même optique, php génére une erreur quand on tente une division par zéro. Pour autant, j'imagine que tu vérifie la valeur du diviseur avant l'opération plustôt qu'attendre l'erreur généré par php.
 
Moi, dans les deux cas, je code de la même maniére : en vérifiant au préalable les données afin d'éviter au maximum les erreurs plustôt que de baser le bon fonctionnement sur la gestion des erreurs.

Je fais pas de PHP, et je catche l'exception qui va bien quand il y a un risque de division par 0

Juste en passant... Pour des questions de "sécurité" et pour lutter contre le spam, ne faut-il pas stocker les emails décomposés dans une base de données, c'est-à-dire dans plusieurs champs...
 
C'est beaucoup plus lourd, j'en convient... Mais c'est juste une question comme ça...

À moins que ton site ait suffisament de failles pour permettre aux robots d'attaquer directement ta BDD, je ne vois pas trop quel intérêt ça aurait

Je suis d'accord avec masklinn, normalement, aucun robos n'aura d'accés direct à ta base de donnée. C'est plustôt à l'affichage qu'il ne faut pas afficher les email en clair surtout dans les pages accéssible sans login.

ça y est ; j'ai enfin trouvé, et ça marche !!!  
Pour ceux que ça intéresse, j'ai en fait mis deux "if" l'un après l'autre.
 
Merci à tous pour votre aide.

masklinn et Arjuna >
 
C'est dirty de se baser sur le message texte de retour, car c'est entièrement dépendant du connecteur. Même sans parler de changer de DBMS - ce qui est peu réaliste, surtout avec du PHP "standard", passons - une simple mise à jour du connecteur ou un changement de langue risque de casser ton code.
 
De plus, commencer à parser ce que renvoit le DBMS, c'est écrire de la plomberie bas niveau. Car ne rêvons pas : on aura pas un bel objet avec une belle méthode qui renvoie le nom de la contrainte violée.
 
En cas de changement de la contrainte au niveau DB, p.e. parce qu'une contrainte nomée changerait de nom, ou qu'on déciderait de la remplacer par un trigger, ou qu'on déciderait de s'en passer pour je ne sais pas quelle bonne ou moins bonne raison, même problème.
 
En théorie, c'est votre approche qui est la bonne : le DBMS devrait faire le boulot et annoncer le résultat. Plus logique et plus efficace. Mais en pratique, que voulez-vous madame, on fait avec ce qu'on a.
 

Autre solution alors : un trigger qui gère l'exception standard, et renvoie une jolie phrase. Et alors on affiche l'exception renvoyée par le SGBD, ce qui correspond à la phrase
 
Si on couple avec une plage dédiée aux numéros d'erreur utilisateur, on peut gérer le cas de l'erreur inconnue sans risque aussi.