bonjour qq1 pourra t 'il m'aider ?

voici le code



j'obtient sa comme erreur

Erreur SQL !INSERT INTO tracks_tbl(titre, artiste, label, genre,) VALUES('titre','artiste','label','genre')
Erreur de syntaxe près de ') VALUES('titre','artiste','label','genre')' à la ligne 1

merci de votre aide

ben fo juste que tu mettes des $ dans ta requete devaznt les noms de variable, la tu balances du texte dans la table et non la valeur de tes variables. d'autre part, dans ton insert, apres le nom de la table, pas besoin de repreciser l'ordre des champs car le insert insere les donnees dans l'ordre ou tu les insere.

INSERT INTO tracks_tbl VALUES ('$titre', '$artiste', '$label', '$genre');

bon sinon au debut de ton code tu fais 2 tests pour savoir si la variable est affectee ou non, 1 des 2 (voire les 2) est inutile ! au lieu d'affecter tes variables en disant $machin=$_POST['machin'] utilises directement $_POST['machin'], c'est pareil en gros vires tes 10 premieres lignes de php, elles servent a rien.

enfin bon... comme tu le sens ! dernier truc, au lieu de faire bosser ton serveur pour verif les champs, ajoutes un code javascript pour que les champs soient testes AVANT l'envoi du formulaire, comme ca ca evite du boulot inutile a ton serveur

autre point important, dans ta table, il faut creer un index, sinon, bonjour les doublons...

bon courage

nikel merci grabber
qu'appelle tu un index ?

comment faire ça ?

sinon j'ai rajouté un id

Le 09 avril 2005 - 16 h 33, Xone a écrit : $sql = "INSERT INTO tracks_tbl(titre, artiste, label, genre,) VALUES('$titre','$artiste','$label','$genre')";

Je pense que cette virgule en trop peut-être la source de l'erreur syntaxique

INSERT INTO tracks_tbl(titre, artiste, label, genre,) VALUES('titre','artiste','label','genre')

Regarde apres genre, t'a une virgule toute seule! L'erreur viens de la!

EDIT :

Le 09 avril 2005 - 16 h 47, grabber a écrit :enfin bon... comme tu le sens ! dernier truc, au lieu de faire bosser ton serveur pour verif les champs, ajoutes un code javascript pour que les champs soient testes AVANT l'envoi du formulaire, comme ca ca evite du boulot inutile a ton serveur

C'est une mauvaise idée de ne pas vérifier les données soumises par l'utilisateur avant utilisation par le serveur. Si tu fais la vérif. en javascript, coté client, un bidouilleur peut bricoler une "attaque" de ta base, tandis que si tu fais les tests de validité coté serveur, tu es plus tranquille.

C'est mon opinion de parano averti

Le 10 avril 2005 - 12 h 21, DeVice a écrit : Le 09 avril 2005 - 16 h 47, grabber a écrit :enfin bon... comme tu le sens ! dernier truc, au lieu de faire bosser ton serveur pour verif les champs, ajoutes un code javascript pour que les champs soient testes AVANT l'envoi du formulaire, comme ca ca evite du boulot inutile a ton serveur C'est une mauvaise idée de ne pas vérifier les données soumises par l'utilisateur avant utilisation par le serveur. Si tu fais la vérif. en javascript, coté client, un bidouilleur peut bricoler une "attaque" de ta base, tandis que si tu fais les tests de validité coté serveur, tu es plus tranquille. C'est mon opinion de parano averti

l'un n'empeche pas l'autre, mais je persiste, il est inutile de faire bosser le serveur si aucun champ requis n'est rempli. apres, libre a toi de faire les tests que tu veux sur tes donnees en aval, mais avant de tester la validite d'une info, il faut que l'info soit presente
la bande passante est un parametre important, tout comme les connexions simultanees sur mysql, et imposer a l'utilisateur un rechargement supplementaire de la meme page si certaines donnees requises sont absentes est hors de propos, c'est d'ailleurs a cela que sert javascript, tester les evenements
je suis donc en partie daccord avec toi seulement

... et c vrai t un peu parano lol, mais je suis un peu comme toi donc

pour l'interesse en ce qui concerne les index : en gros, tu ajoutes une colonne a ta base genre si tu as les colonnes suivantes actuellement :
- titre
- artiste
- label
- genre
tu ajoutes une premiere colonne "identifiant_chanson" a laquelle tu vas apporter une propriete auto increment lors de sa creation(dans ton phpmyadmin ). lorsque tu vas faire une insertion dans ta base, tu ne t'occupes pas de cette identifiant qui va etre gere tt seul. auto-increment fa&it que lors de la 1ere insertion dans ta table, les donnees porteront l'ident 1, la seconde serie l'identifiant 2, etc. l'interet de l'autoincrement est d'eviter les doublons, par exemple si tu tapes 2 fois la meme chanson dans ton formulaire, tu auras un doublon pas avec l'index car il n'est pas falsifiable. imaginons que tu aies entre 3 titres dans ta table, avec comme index 1, 2 et 3, si tu supprimes le 2, ta table commencera avec le 1, puis le 3 (car le 2 est supprime). si tu ajoutes une nouvelle chanson, elle aura l'identifiant 4, et le 2 ne sera plus jamais utilise
la methode des index permet egalement de "classer" par ordre d'arrivee tes enregistrements des plus recents aux plus anciens pourquoi pas !

tu comprends ?

la seule facon de reinitialiser les index fait avec autoiincrement sans supprimer une table et la recreer serait de faire un truncate, qui aurait pour effet de vider la table et de reinitialiser les index sans aneantir la strucutre de la dite table.

oui je comprend c'est justement ce que j'avais fais

petite question comment on fait pour coder un pass par dans une base mysql
?

encodage md5

sinon y a une fonction PASSWORD dans mysql si tu veut.
Utilisation : INSERT INTO `ma_table` (`...`, `...`, `...`) VALUES ('...', PASSWORD('monpass', '...');

Le 12 avril 2005 - 00 h 47, Woofy a écrit : sinon y a une fonction PASSWORD dans mysql si tu veut. Utilisation : INSERT INTO `ma_table` (`...`, `...`, `...`) VALUES ('...', PASSWORD('monpass', '...');

attention a cette fonction !!!
elle a evolue au cours des versions de mysql, ce qui veut dire que des pass crees avec telle version ne seront pas forcement operationnels suite a une maj de mysql ! je deconseille donc a moins d'etre sur de la maitrise des updates

http://www.nexen.net/docs/mysql/annotee/password-hashing.php?lien=suivant

arf!
Merci pour le lien!

Le 11 avril 2005 - 00 h 11, grabber a écrit : Le 10 avril 2005 - 12 h 21, DeVice a écrit : Le 09 avril 2005 - 16 h 47, grabber a écrit :enfin bon... comme tu le sens ! dernier truc, au lieu de faire bosser ton serveur pour verif les champs, ajoutes un code javascript pour que les champs soient testes AVANT l'envoi du formulaire, comme ca ca evite du boulot inutile a ton serveur C'est une mauvaise idée de ne pas vérifier les données soumises par l'utilisateur avant utilisation par le serveur. Si tu fais la vérif. en javascript, coté client, un bidouilleur peut bricoler une "attaque" de ta base, tandis que si tu fais les tests de validité coté serveur, tu es plus tranquille. C'est mon opinion de parano averti l'un n'empeche pas l'autre, mais je persiste, il est inutile de faire bosser le serveur si aucun champ requis n'est rempli. apres, libre a toi de faire les tests que tu veux sur tes donnees en aval, mais avant de tester la validite d'une info, il faut que l'info soit presente la bande passante est un parametre important, tout comme les connexions simultanees sur mysql, et imposer a l'utilisateur un rechargement supplementaire de la meme page si certaines donnees requises sont absentes est hors de propos, c'est d'ailleurs a cela que sert javascript, tester les evenements je suis donc en partie daccord avec toi seulement ... et c vrai t un peu parano lol, mais je suis un peu comme toi donc

securité !!!
=> il faut faire les deux:
- coté client pour traquer au maxi les erreurs utilisateur => evite de "surcharger" le serveur et permet d'interagir plus rapidement avec l'utilisateur (style la popup js pour lui signifier: "oups, la t'as mis un truc qui va pas..")
- coté serveur: surtout pour se premunir des mauvaises surprises, style le champ rempli avec une quote (') et ce qui va bien derriere.... => il y a une fonction php/mysql que je conseille d'utiliser: mysql_escape_string


pour le md5 => php a une jolie fonction md5...

EDIT: juste pour mettre en evidence mysql_escape_string...

Le 12 avril 2005 - 12 h 20, tempo a écrit : Le 11 avril 2005 - 00 h 11, grabber a écrit : Le 10 avril 2005 - 12 h 21, DeVice a écrit : Le 09 avril 2005 - 16 h 47, grabber a écrit :enfin bon... comme tu le sens ! dernier truc, au lieu de faire bosser ton serveur pour verif les champs, ajoutes un code javascript pour que les champs soient testes AVANT l'envoi du formulaire, comme ca ca evite du boulot inutile a ton serveur C'est une mauvaise idée de ne pas vérifier les données soumises par l'utilisateur avant utilisation par le serveur. Si tu fais la vérif. en javascript, coté client, un bidouilleur peut bricoler une "attaque" de ta base, tandis que si tu fais les tests de validité coté serveur, tu es plus tranquille. C'est mon opinion de parano averti l'un n'empeche pas l'autre, mais je persiste, il est inutile de faire bosser le serveur si aucun champ requis n'est rempli. apres, libre a toi de faire les tests que tu veux sur tes donnees en aval, mais avant de tester la validite d'une info, il faut que l'info soit presente la bande passante est un parametre important, tout comme les connexions simultanees sur mysql, et imposer a l'utilisateur un rechargement supplementaire de la meme page si certaines donnees requises sont absentes est hors de propos, c'est d'ailleurs a cela que sert javascript, tester les evenements je suis donc en partie daccord avec toi seulement ... et c vrai t un peu parano lol, mais je suis un peu comme toi donc securité !!! => il faut faire les deux: - coté client pour traquer au maxi les erreurs utilisateur => evite de "surcharger" le serveur et permet d'interagir plus rapidement avec l'utilisateur (style la popup js pour lui signifier: "oups, la t'as mis un truc qui va pas..") - coté serveur: surtout pour se premunir des mauvaises surprises, style le champ rempli avec une quote (') et ce qui va bien derriere.... => il y a une fonction php/mysql que je conseille d'utiliser: mysql_escape_string pour le md5 => php a une jolie fonction md5...

c'est justement ce qui est ecrit

On est d'accord : les deux, c'est mieux

Le 12 avril 2005 - 21 h 41, DeVice a écrit : On est d'accord : les deux, c'est mieux

a 2 c toujours mieux lol (oula, chui en forme... )

oui mais deux bouts, c'est mou...

La sortie c'est où ? Ah ! c'est là.