Anonymus

Je n'avais pas vu qu'il s'agissait d'OutlookExpress. Bon, je recommence : Fichier>Identités>Gérer les identités>Supprimer, il ne se passe rien ? Bon, fais des tests sur le répertoire suivant : C:\Documents and Settings\Anonymus\Application Data\Identities (tu changes Anonymus par ton 'profil') Les différentes clé (p.e. {7A4DE86B-7C95-4315-B19F-7B89658D2EA3}) sont en fait les différentes identités. Nico.

Aucun problème, et les légers ralentissements que tu pourrais rencontrer commenceraient à partir d'un bon millier d'icones (et encore..) Quel champ ?

En fait, il existe plusieurs solutions, mais la tienne est assez 'pro', elle marche bien, et les variables sont faites pour ca. Tu peux t'arracher les cheveux avec la méthode suivante, mais.. est ce bien utile ? Autre méthode : - Mettre tout en 'buffer', avec les fonctions de bufferisation (flush,..) - Récupérer le contenu du buffer dans une variable, - parcourir cette variable pour enregistrer le contenu des <title>, et le placer ailleurs dans le code. Ca peut être utile de faire comme ca dans certains cas, mais... est ce bien utile de se prendre la tete avec des méthodes complexes ? Nico.

Bonjour, qu'est ce que donne : Outils>Comptes de messageries>Afficher ou modifier les comptes>supprimer. ? Vois tu ce compte ? Peux tu le supprimer ? Le modifier ?

Il en existe beaucoup plus que ce qui est listé dans la partie 'outils' du hub, mais le principe n'est pas forcément de les lister tous, mais de mettre un échantillon représentatif.

Bien vu, c'est exactement la méthode à adopter. Logiquement : A une icone correspond une et une seule catégorie. Donc, id_cat va dans la table image. La table icone_cat ne te sert plus à rien. En fait, elle pourrait servir si tu affectais une à plusieurs catégories par icone, et une à plusieurs icones par catégories. Sans ces 2 conditions, il n'y a pas besoin de table de jointure. Pour info, s'il y en avait eu une, elle n'aurait pas de clé. Pourquoi ? Parce que les 2 clés (id_icone et id_cat) forment une clé à elles seules. Ainsi, le 'couple' id_icone 1 et id_cat 3 doit être unique. (quoique, mais.. c'est pour simplifier..)

A supposer que toutes tes images se trouvent systématiquement dans le répertoire images/, alors tu n'es pas obligée de mettre ce nom dans la base. C'est inutile. Pour l'image 1, tu afficheras echo "<img src='http://gribouille.com/image/".$IMAGE1."'>"; et ca affichera <img src='http://gribouille.com/images/dossier/img01.jpg'>

A partir du domaine gribouille.com, par exemple. Si toutes tes images sont dans le répertoire : gribouille.com/images/ alors tu n'as pas besoin de stocker quoique ce soit. Quand tu as besoin d'une image, tu mets : <img src="images/".$nom_de_l_image."> Si tes images sont stockées dans des répertoires différents, tu as plusieurs solutions. Soit tu stockes l'url avec le nom de l'image dans la base de données, ca donnera : id_image nom_image cat_image avec nom_image correspondant par exemple à /vacances/plage.jpg Soit tu stockes juste le nom de l'image (plage.jpg), mais tu ajoutes une colonne repertoire_image, dans lequel tu mets /vacances, voir "1", avec dans ce cas soit un tableau dans un fichier configuration.php, qui renverrait $tableau_repertoires_images[1]="/vacances"; Soit tu créées un table sql, pour stocker les noms des répertoires, avec un 'id_repertoire, que tu répercutes dans la table 'images'. Bref, il existe vraiment plusieurs solutions. Mais en fait, il faut prendre le problème à l'envers. Savoir exactement ce que l'on veut, et à partir de là, prendre des choix. Il n'y a pas de meilleur ou de moins bon choix, mais chacun d'entre eux implique des obligations. Exemple : Faire un tableau des répertoires dans le fichier config.php implique qu'il sera beaucoup plus difficile d'ajouter des répertoires, sans passer par un 'upload' du fichier. D'un autre coté, mettre les répertoires dans la base de données peut avoir 2 inconvénients : 1/ rapidité d'accès (si tu sépares les répertoires dans une table externe 2/ place occupée, si tu stockes les répertoires avec les images.

Le problème est que c'est une donnée beaucoup trop importante, qui se vend à prix d'or, et que l'on ne donne pas à n'importe qui. (on = ceux qui ont cette info) En fait, peut etre aussi que le problème est que personne ne maitrise vraiment ces infos. Il est possible de faire des suppositions, des stats, mais.. Qui va compter les mots entre tels et tels sites, s'ils ne sont pas affiliés ?

Plusieurs mots dans un champ ? Si c'est pour une recherche : 1/ sans caractères spéciaux, 2/ sans accents, 3/ en minuscules, 4/ séparés par un espace, 5/ rangés par ordre alphabétique (pourquoi ? parce que.. ) voilà à peu près.. Pour ce qui est des 'url', il y a 2 cas. Soit tu n'as pas 2 images stockées au même endroit, auquel cas il est intéressant de stocker les url, soit elles sont toutes au même endroit (par exemple dans le répertoire /images) , auquel cas tu peux mettre ce chemin dans un fichier config.php Nico.

1/ Un conseil, fais une copie de la base, et teste ta requète sur une base en local. 2/ Le problème, c'est que tu n'as pas d'identifiants à tes tables. Tu ne peux comparer un champ avec l'autre, pour avoir l'ordre par exemple. 3/ Les champs 'date' ne sont pas forcément valables pour ce genre de manipulations. De plus, on ne sait pas sous quelles formes ils se présentent (DDMMYYYY, ou YYMMDD, ..) 4/ Mets un champ id si tu veux éviter tout problème. 5/ Ensuite, les requètes ressembleront à ceci : En premier : select id from table order by 1 desc limit 0,5000 Là, tu récupères le dernier id (last_id) Puis : delete from table where id<last_id Voilà.

Tu as un exemple (valide) d'url telle que celles qui ne marchent pas ? merci.

Si, ca aurait marché, mais : 1/ Qu'est ce que : cle_image ? 2/ L'idée des bases de données, c'est aussi de stocker sous forme 'optimisée', des données qui se répètent. Donc, dans le cas que tu donnes, tu te retrouverais avec ceci : id_image cat_image 1 humour 2 policier 3 triste 4 humour 5 Humour 6 tristre 7 humour et quand tu vas chercher les différentes catégories, il ne les trouveras pas, à cause des différentes erreurs. La requète : select id_image from image where cat_image='humour' ne fera pas ressortir le site 5 par exemple ('H' majuscule). Avec la méthode que je donne, ca parait un peu plus compliqué, mais la requète donnera toujours toutes les images qui correspondent à 'humour', vu que la catégorie sera 'unique' dans la base de données. Pour ce qui est du 'nom_image', c'est dans l'hypothèse où tu donnes des noms à tes images. Ainsi, quand tu regarde ton répertoire, tu sais tout de suite ce qu'est telle ou telle image. Si tu veux mettre un identifiant numérique au lieu d'un identifiant et d'un nom, et si tu veux appeler les images avec cet identifiant, c'est possible aussi, pourquoi pas, mais c'est plus 'abstrait'.

Par contre, on peut supposer que tu as la preuve de ton achat, or le vendeur n'a pas la preuve de sa vente. Tu pourrais très bien demander au tribunal que te sois fourni le service payé, mais.. encore une fois, si c'est pour un ou deux appels, est ce que ca en vaut bien la peine ? même si c'est malheureux à dire.. S'il ne répond pas à tes mails, fais lui une bonne pub (mais pas sur le hub !! )

Cours de mysql pour débutant ? Ca se trouve sur le Hub http://www.webmaster-hub.com/publication/r...recherche=mysql Si tu as besoin d'autres conseils, ou si tu n'as pas compris un passage, n'hésites pas à demander pour info, et pour compléter ce que dit 'MarvinLeRouge', voici ce que ca donnerait : table categorie => id_cat nom_cat table image_cat => id_cat id_image table image => id_image nom_image Sachant que les chemins vers les répertoires image seront stockés dans un fichier config.php.

Bonjour, Pour la société Studyrama, j'ai mis en place un programme de bannières géolocalisées. Le principe est simple, on affiche la bannière qui correspond à votre localisation. Ainsi, si vous habitez Lyon, on affiche une bannière correspondant à Rhone Alpes. J'ai donc besoin de votre aide, pour tester ces bannières, voir si le fichier région<-> ip est cohérent, si le programme marche convenablement, etc... <edit: le lien a changé, il faut aller sur : http://adserver.studyrama.com/sondage.php : > Donc, veuillez suivre ce lien : http://adserver.studyrama.com/sondage.php rafraichir 4 - 5 fois, et nous dire quelles bannières vous voyez (il devrait y en avoir plusieurs.. ) Il serait aussi sympa de nous indiquer par quel FAI (aol, free,..) vous passez, histoire de voir s'il est possible d'isoler les fai pour lesquels ca ne marche pas. Enfin, votre 'vraie' localisation nous sera utile Donc : <edit: le lien a changé, il faut aller sur : http://adserver.studyrama.com/sondage.php : > 1/ le lien : http://adserver.studyrama.com/sondage.php 2/ 4 - 5 rafraichissements de page, 3/ nous indiquer, à la suite de ce post : localisation, bannières vues, FAI. Merci d'avance, Nicolas ps : L'image bleue sert de test, vous pouvez nous dire ce que vous y voyez merci

Je me demandais, si, en fait : HTTP________-->----:----------------------------------------------------------------- ne correspondrait pas à : HTTP_REFERER = ... (caché) Etrangement, HTTP________ et HTTP_REFERER font le même nombre de caractères :/

.. Je ne sais pas non plus pourquoi ils font ca.. c'est pire, je fais pareil ..

Si ca peut aider quelqu'un à nous trouver ce qui cause ces lignes, voici la réponse à la requète : foreach($_SERVER as $k=>$v)echo"<br>SERVER: ".$k."-->".$v; (juste modifié 2-3 p'tits trucs.) Je bloque carrément les personnes qui viennent comme ceci, et les invite à me contacter. Après tout, si quelqu'un vient chez moi avec une cagoule, je vais attendre qu'il l'enlève pour lui ouvrir

Certaines sources (clubic, justement) disent plutot le contraire.. http://www.clubic.com/actualite-17926-pas-...avant-2006.html (pas de nouvelle version d'IE avant 2006, voire avant le lancement de LongHorn)

Le HTTP_REFERER donne une idée générale du site d'où viennent les internautes. Ca peut etre utile pour des statistiques, etc, mais il est vrai que, comme tout entete, il n'est pas fiable au niveau 'sécurité'.

D'après ce que je comprend du validateur, il ne peut vérifier ton document, ce qui n'est pas pareil. Il te donne d'ailleurs les lignes qui contiennent des caractères qu'il ne comprend pas. Ensuite, tu pourras le repasser. Pour ce qui est des moteurs, ils suivent les liens trouvés sur internet, et ils se servent la plupart du temps du texte qu'ils trouvent dans le corps de la page, donc entre les balises <body>. Beaucoup de moteurs ne tiennent plus du tout compte des balises meta.

Je l'avais déjà remarqué, mais.. là, j'ai besoin d'une réponse.. Pour le HTTP_WEFERER, la réponse est donnée sur le site php : Autrement dit, le firewall Norton Personnal Firwall change le HTTP_REFERER en HTTP_WEFERER, et l'encrypte. On peut imaginer des soft qui permettent de cacher les HTTP_REFERER, voire de modifier leurs entètes, leur nom, et de renvoyer de 'fausses informations', voire des informations incohérentes..

Je cherches à savoir qui vient sur mon site, or je me retrouve avec des lignes comme celle ci : Pourtant le programme destiné à afficher ces données est sans surprises : foreach($_SERVER as $k=>$v)echo"<br>".$k."->".$v; Encore le HTTP_WEFERER pourrait être normal.. mais les autres Si vous aviez une idée, leur nombre est tout de même assez élevé (je veux dire.. le nombre de personnnes qui envoient ce genre de requetes )

En fait, honnètement, je n'y comprend pas grand chose.. Tant que ca marche et.. Oh, ca marche !! Merci