TOUJOURS quoter (au sens SQL) un littéral texte. Utilise _SQLite_Escape pour protéger ton littéral (doubler d'éventuelles apostrophes dans le littéral).
La version _SQLite_Escape proposée par l'UDF est très lourde et les modifs que j'y ai apportées ne sont pas encore sorties (pas de version release depuis). Perso, j'emploie X() pour le premier littéral texte et XX() pour les suivants :
Code : Tout sélectionner
Func X($s)
Return ("'" & StringReplace($s, "'", "''", 0, 1) & "'")
EndFunc ;==>X
Func XX($s)
Return (",'" & StringReplace($s, "'", "''", 0, 1) & "'")
EndFunc ;==>XX
Func Y($s)
Return ("X'" & Hex($s) & "'")
EndFunc ;==>Y
Func YY($s)
Return (",X'" & Hex($s) & "'")
EndFunc ;==>YY
Func Z($s)
Return (Number($s))
EndFunc ;==>Z
Func ZZ($s)
Return ("," & Number($s))
EndFunc ;==>ZZ
Ton SQL devient :
XX() est à utiliser pour les champs suivants car cette fonction insère une virgule. Y() et YY() font la même chose pour des variables binaires, Z() et ZZ() pour des valeurs numeriques.
Les noms très courts que j'emploie ne sont certes pas assez parlants, mais le nouveau nom proposé est trop lourd à mon goût _SQLite_FastEscape($variable). Je préfère X() et ses petis frères pour la lisibilité, par exemple :
Code : Tout sélectionner
_SQLite_Exec($hADB, "insert into _Anomalies (Quand, Quoi, Reference, Texte) values (" & _
X(_NowCalc())& _
XX("Fiche de vente")& _
ZZ($fiche[$fv_numfiche])& _
XX("Code postal invalide.") & ");")
Si un jour le dernier libellé devient
Le code postal n'est pas valide l'opération fonctionnera encore normalement. Sinon, BOUM !
Revenons à ta chanson...
Premier hiatus AMTHA : il te faut découpler l'URL du titre. Si l'URL disparaît, le titre ne doit pas disparaître, mais devenir indisponible (temporairement ou --bien moins probablement-- définitivement). Un titre peut aussi avoir plusieurs URLs, parfois le même enregistrement mais dans des formats distincts (Flac ou MP3, avec clip vidéo ou pas, que sais-je ?). Un titre aura vraissemblablement plusieurs versions (single, album, concert ici ou là, version instrumentale, ...).
Tu "sens" que ces deux données sont liées, mais ont une certaine indépendance qu'il vaut mieux se donner les moyens de retranscrire dans la base. Une base est justement faite pour ça : assurer des liens relationnels éventuellement complexes entre des données de nature différentes.
Si tu laisses tout en vrac dans une seule table, tu arrives vite à un sac de noeuds pour l'usager : 156 versions différentes et non classées d'un seul et même titre de tel artiste. Même si tu n'as pas l'ambition de rivaliser avec freedb (voir le site) il est intéressant de s'inspirer (tout ou partie) de ses principes de fonctionnement. freedb ou autre, évidemment. Rien ne t'empêche non plus de viser la compatibilité avec freedb (éventuellement à terme).
Rien de cela n'est envisageable avec des moyens de stockage rudimentaires (fichier plat ou assimilés) tndis que mettre en oeuvre une base décente n'est pas très compliqué et surtout s'avèrera beacoup plus simple à gérer si tu fais évoluer ta réalisation.
Ici comme ailleurs bien souvent, ce n'est que le premier pas qui compte.
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
), une URL, avec le lien complet de la chanson, et le second IDTAG, avec le tag de la chanson.