Ca marche pas en tout cas (testé et pas approuvé)

La seule solution pour utiliser de l'UTF avec MySQL 3 (et qui fonctionnait!) c'était de faire un encodage hexa, je sais pas si tu imagines la merde

Pas sûr, mais j'ai l'impression que antp a raison... Du moment que tu te fous de faire tes recherches case insensitive etc, un string utf-8 n'est pas distinguable d'un string C (nul terminé)
Alors pourquoi tu ne pourrais pas le mettre dans un champ MySQL ?

Edit: utf-8 n'est pas compatible ASCII car il peut contenir des bytes >= 128. Mais ISO8859-xx aussi, alors...

Ecoute, d'expérience, en UTF-8, MySQL 3 m'a bousillé tout mes champs. J'avais cherché et un mec avait eu les même soucis, je suis pas le seul blaireau a pas avoir réussi a faire bouffer de l'UTF-8 à PHP4+MySQL3 sans passer par de l'hexa

Postgres je t'aime

sauf que leur package debian est moyen moyen..
derniere fois le daemon demandais à init un mot de passer pour se lancer.. je vais placer un nigérien au datacenter pour tapper le mot de passe quand je reboot le serveur

Non, sans blague, j'ai un mal de chien à comprendre le fonctionnement de pg_conf et ses copains authenfication..

Si non, bouée pourquoi pas une base Postgres8 plutôt que MySQL5

Heu je ne me souviens plus vraiment mais quand j'ai eu mon projet à faire pour l'unif, je m'étais retrouvé avec des trucs impossible ou buggé sous mysql qui fonctionnait à merveille sous postgresql.

2 exemples :

- les view plantaient régulièrement sous mysql
- pas moyen de rejetter l'insertion d'une entrée sous mysql si elle ne répondait pas aux contraintes de la table (Je ne sais même plus si mysql supportait des contraintes complexes. Je pense qu'il les acceptait mais ne les utilisaient pas, je te dis pas le bordel).

ça date tout cela. C'était sans doute valable du temps de MySQL 3.23, mais maintenant ce genre de bourde ont été corrigée (même s'ils ont toujours pas foutu au feu leurs moteurs heap et MyIsam ). Par contre, niveau trigger, ils ont encore du boulot à faire (en fait pour tout ce qui est stored procédure, c'est naze). De même que sur leur gestion des valeurs par defaut.

gizmo > ça date de mysql 5.01 alors non ça n'est pas corrigé ou alors pas complètement

Alors, c'est que tu ne sais pas l'utiliser MySQL est un mauvais DBMS, mais les problèmes que tu décris ont été résolu depuis un petit temps maintenant.

Mauvais faut pas exagérer non plus hein gigi.. je suis passé par ASP1 et Access moi alors..

J'ai pas dit que c'était le pire non plus, hein. On parle pas de dbase non plus

Sinon dans le genre pire il y a Paradox aussi

M'en parle pas, chuis obligé de l'utiliser au boulot Et de faire des imports-exports avec du mysql en php

Lol gizmo, prend moi pour un demeuré complet merci j'apprécies La même chose sous postgresql ne posait aucun problème (enfin fallait traduire les triggers mais bon c'est pas la mer à boire) alors faut pas exagerer mysql est pourrit point à la ligne. Faut pas essayer de lui trouver des excuses comme quoi il fallait faire autrement. Il y a une norme et elle doit être respectée si non on va se cacher. C'est comme coder un compilateur c++ mais qui n'est pas iso c++. Faut arrêter de fumer la moquette à un moment.

Si je dois apprendre des techniques spéciales pendant 2 ans pour un sgdb, je préfère de loin apprendre pour oracle qui est quand même largement plus performant que cette merde de mysql.

P.S. Pour de petites bases de données mysql est très bien mais quand tu veux faire quelque chose d'un tant soit peu evolée mysql rame ou ne supporte pas.

C'est gizmo, il aime se faire des amis

Paradox c'est les scendres de Interbase ça, non?

Euh, je voulais dire l'inverse..

Firebird c'est les cendres d'Interbase

La préhistoire d'Interbase peut-être, mais je doute qu'il y ait vraiment un lien entre les deux à part le fait que ça vienne de Borland.

Ah oui

j'my perds moi