> J'utilise la version 1.2.1_p2 de chez OVH, je suis en mutualisé !
>
> Plus de détails sur l'erreur :
> /usr/lib/python2.4/site-packages/MySQLdb/cursors.py in
> execute(self=<MySQLdb.cursors.Cursor object>, query="UPDATE proprietaire
> \n SET civil...'ma', notaire_id = 1\n WHERE id = 1", args=None)
> 144 db = self._get_db()
> 145 charset = db.character_set_name()
> 146 query = query.encode(charset)
> 147 if args is not None:
> 148 query = query % db.literal(args)
> query = "UPDATE proprietaire \n SET civil...'ma', notaire_id = 1\n WHERE
> id = 1", query.encode = <built-in method encode of str object>, charset
> = 'latin1'

Ce ressemble bien au bug que j'avais identifié (ligne 146).
Tu peux essayer de passer un unicode à la place d'un string :
ex : sqlTxt = unicode('insert..."Rémi"...etc..','iso-8859-1')
instruction_sql(sqlTxt)
Le iso-8859-1 colle bien si tu es sous windows. Si tu es sous linux, ce
serait plutôt utf-8, tout dépend du charset dans lequel le programme a
été saisi.
Tu peux aussi installer la dernière version de MySQLdb dans ton espace
perso ; tout dépend de la quantité de modifs que tu devras faire dans
ton code pour passer des unicodes au lieu des strings. Si tu en as
beaucoup, ça vaut le coup d'essayer d'installer cette dernière version.

Quand tu auras passé un unicode, la ligne 146 retransformera cet unicode
en string dans un charset qui sera supposé plaire à MySQL, et ça devrait
fonctionner. L'idée de tout ça est de gérer automatiquement la
translation du charset du programme vers le charset de la base. L'idéal
serait de commenter la ligne 146 qui ne sert à rien si tu n'as qu'un
jeux de caractères à gérer.

Tout ça n'a visiblement pas trop bien été testé au départ par notre bon
Andy Dustman, qui a probablement autre chose à faire que de se
préoccuper des caractères accentués et autres étrangetés étrangères...

Bon courage,
jm