Questions sur MySQL avec OO_Base

Bonjour,

Bernard wrote:

J'ai donc désormais une serveur mysql, et j'essaye de gérer l'essentiel
via l'interface proposée par OO_Base. C'est un peu lent (3 minutes pour
parcourir une base de 65,000 enregistrements du premier au dernier, 6
minutes pour une base de 115568 enregistrements de 19 champs d'en moyenne
50 octets CHAR chacun), mais c'est gérable.

Tu peux installer un phpMyAdmin sur ta machine, ou mysql workbench, ou
utiliser mysql en ligne de commande, ce sera peut-être plus rapide.

D'abord, cette base MySQL, comment en fait on des sauvegardes ?
J'ai trouvé que, sur mon système, les bases sont stockées dans:
/var/lib/mysql/'nombase'/
Comment puis-je copier ces bases, sur un cdrom, une clef usb ou un disque
externe par exemple ? Puis-je compresser ces fichier avant de les
sauvegarder ?

Tu peux tout à fait faire une archive du répertoire, il suffira de la
décompresser au bon endroit sur ton autre machine et ça tournera.

Par ailleurs, il est une autre question que je me pose. Pour cette fois,
j'ai inséré mes données dans la table par 'copié/collé' depuis un fichier
calc, c'est à dire que je l'ai fait en deux fois. Est-il possible, en
faisant usage de OO Base, de copier directement à partir d'un fichier
texte csv avec des données séparées par des point virgules ? J'ai
constaté qu'en copié collé ce n'était pas possible, ce dont je me doutais
un peu.

Je ne connais pas trop OO_Base mais cela doit être possible. J'imagine
qu'il y a des fonctions d'import.
Si tu as un fichier CSV, tu peux aussi l'importer dans mysql soit avec
phpMyAdmin, soit en ligne de commande.


--
Réseau IRC Francophone: http://www.zeolia.net
Aide et astuces : http://www.g33k-zone.org
Communauté Francophone sur les Eggdrops: http://www.eggdrop.fr

Bonjour,

On Wed, 07 Oct 2009 16:56:32 +0200, CrazyCat wrote:

Bernard wrote:

D'abord, cette base MySQL, comment en fait on des sauvegardes ?
J'ai trouvé que, sur mon système, les bases sont stockées dans:
/var/lib/mysql/'nombase'/
Comment puis-je copier ces bases, sur un cdrom, une clef usb ou un disque
externe par exemple ? Puis-je compresser ces fichier avant de les
sauvegarder ?

Tu peux tout à fait faire une archive du répertoire, il suffira de la
décompresser au bon endroit sur ton autre machine et ça tournera.

Petite information supplémentaire, il faut aussi éviter de le faire
pendant des écritures dans la base. On peut stopper le serveur, ou
exécuter les commandes suivantes :

LOCK TABLES table_1, table_2…
FLUSH TABLES table_1, table_2…

mysqlhotcopy (fourni avec MySQL) est très pratique pour ça.

Sections intéressantes de la doc :

http://dev.mysql.com/doc/refman/5.1/en/backup-methods.html
http://dev.mysql.com/doc/refman/5.0/en/mysqlhotcopy.html

--
Thibault Jouan
A13 http://a13.fr/
+33 6 28 25 39 00

CrazyCat wrote:

Tu peux tout à fait faire une archive du répertoire, il suffira de la
décompresser au bon endroit sur ton autre machine et ça tournera.

A déconseiller cependant. Il ne faut pas oublier que ce sont des
formats binaires. Bref, la version de MySQL, celle du compilateur (ABI
incompatible, MySQL est écrit en grande partie en C++), le processeur
cible (endieness, taille du mot, etc).
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Bernard wrote:

Bonjour à tous,

Je précise tout de suite que je débute sur les bases de données, et que,
autre singularité, je ne travaille pas sous MSWIN, mais sous Linux
(Debian Lenny pour mon desktop, Ubuntu Hardy Heron sur mon laptop).

Jusqu'alors, je me contentais de gérer mes bases avec StarCalc
(OpenOffice Calc), tableur voisin de MS EXCEL. Lorsque lesdites bases ont
dépassé 65536 lignes, j'ai dû me résoudre à les fractionner, ce qui n'est
pas génial, surtout lorsqu'on doit faire des tris et autres opérations.

Alors j'ai essayé OpenOffice BASE avec MySQL, sur les conseils reçus par
les utilisateurs rencontrés sur fr.comp.os.linux.configuration, lesquels
m'ont recommandé de venir ici pour des questions plus précisément ciblées
sur les bases de données.

J'ai donc désormais une serveur mysql, et j'essaye de gérer l'essentiel
via l'interface proposée par OO_Base. C'est un peu lent (3 minutes pour
parcourir une base de 65,000 enregistrements du premier au dernier, 6
minutes pour une base de 115568 enregistrements de 19 champs d'en moyenne
50 octets CHAR chacun), mais c'est gérable.

Qu'entends-tu par parcourir tes enregistrements ? Juste les afficher à
l'écran ou y effectuer un traitement. Parce qu'en local les temps que tu
annonces me semblent incroyablement longs. Tu n'aurais pas des problèmes
d'index inexistants sur des champs de tri courants ?

A ce stade, je me pose quelques questions, nul doute qu'il y en aura
prochainement davantage.

D'abord, cette base MySQL, comment en fait on des sauvegardes ?

J'ai trouvé que, sur mon système, les bases sont stockées dans:

/var/lib/mysql/'nombase'/

avec user et grp : 'mysql'

Comment puis-je copier ces bases, sur un cdrom, une clef usb ou un disque
externe par exemple ? Puis-je compresser ces fichier avant de les
sauvegarder ?

Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à un
moment de la journée arrêter ta base, alors tu as au moins deux solutions :
faire une recopie avec cp et les options d'archives qui vont bien (man cp)
ou mieux un rsync avec les bonnes options (man rsync),
de /var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).

Si tu ne peux jamais l'arrêter il faut faire ce qu'on appelle
une "sauvegarde à chaud". Si toutes tes tables sont des tables MyISAM et
pas INNODB alors il existe un utilitaire installé sous linux par défaut
avec mysql, un script perl fourni par mysql qui s'appelle mysqlhotcopy qui
sait recopier les tables à chaud, regarde la man mais un exemple de syntaxe
est le suivant :
perl /usr/bin/mysqlhotcopy --user=nomuser --password=xxxxxxxx --allowold --keepold --regexp='motifnombase*.*' /chemin/pourle/backup-mysql

Cette commande va te recopier tous les fichiers de la base dont le nom
commence par motifnombase suivi de n'importe quoi dans le
répertoire /chemin/pourle/backup-mysql bien entendu à toi de choisir où
faire ça. Ensuite cette arborescence sauvée à chaud pour être recopiée avec
rsync. mysqlhotcopy sait gérer les verrous et conserve la base en état
cohérent.

Car si tu te contentais de recopier simplement l'arborescence
de /var/lib/mysql/mabase pendant qu'elle tourne, tu as un pourcentage de
chance frôlant le 100% si ta base est très sollicitée en écriture, de te
retrouver avec un état incohérent à l'arrivée (imagine que tu aies un
insert dans une table, lié avec un insert dans une autre, manque de chance
tu recopies la seconde table avant l'insert et la seconde ensuite avec
l'insert, à l'arrivée ta base est inutilisable ou à tout le moins
incohérente.

Si tu as besoin du moteur INNODB, par exemple pour gérer des transactions ou
l'intégrité référentielle et la cascade, là ton choix est simple : si tu
veux du gratuit tu arrêtes ta base et tu recopies, sinon c'est payant
l'utilitaire un peu équivalent à mysqlhotcopy pour les bases INNODB n'est
pas libre ou en tout cas pas gratuit, il faut l'acheter chez MySQL AB. Si
c'est un truc de boulot tu peux sans doute acquérir cet outil, c'est
beaucoup plus propre, et puis il faut bien qu'ils vivent.

Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la base
dans un fichier texte, souvent sous forme d'instructions SQL d'insert pour
pouvoir recréer les bases et y réinjecter les données en restauration.
Beaucoup plus long que de faire un rsync sur une arborescence à mon goût.

Voilà quelques réflexions basées sur l'expérience et quelques déconvenues
parfois !

Alarch wrote:

Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à un
moment de la journée arrêter ta base, alors tu as au moins deux solutions :
faire une recopie avec cp et les options d'archives qui vont bien (man cp)
ou mieux un rsync avec les bonnes options (man rsync),
de /var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).

Comme je l'ai déjà dit, c'est une très mauvaise idée.

Si tu as besoin du moteur INNODB, par exemple pour gérer des transactions ou
l'intégrité référentielle et la cascade, là ton choix est simple : si tu
veux du gratuit tu arrêtes ta base et tu recopies, sinon c'est payant
l'utilitaire un peu équivalent à mysqlhotcopy pour les bases INNODB n'est
pas libre ou en tout cas pas gratuit, il faut l'acheter chez MySQL AB. Si
c'est un truc de boulot tu peux sans doute acquérir cet outil, c'est
beaucoup plus propre, et puis il faut bien qu'ils vivent.

On peut également utiliser la réplication, et sauvegarder la base
répliquée.

Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la base
dans un fichier texte, souvent sous forme d'instructions SQL d'insert pour
pouvoir recréer les bases et y réinjecter les données en restauration.
Beaucoup plus long que de faire un rsync sur une arborescence à mon goût.

Plus long mais plus fiable. La vitesse est la seule raison pour
laquelle tu n'aime pas dumper ?

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Mickaël Wolff wrote:

Alarch wrote:

Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à
un moment de la journée arrêter ta base, alors tu as au moins deux
solutions : faire une recopie avec cp et les options d'archives qui vont
bien (man cp) ou mieux un rsync avec les bonnes options (man rsync),
de /var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).

Comme je l'ai déjà dit, c'est une très mauvaise idée.

Ah ? pourquoi ? si la base est arrêtée c'est à mon avis la meilleure idée.

Si tu as besoin du moteur INNODB, par exemple pour gérer des transactions
ou l'intégrité référentielle et la cascade, là ton choix est simple : si
tu veux du gratuit tu arrêtes ta base et tu recopies, sinon c'est payant
l'utilitaire un peu équivalent à mysqlhotcopy pour les bases INNODB n'est
pas libre ou en tout cas pas gratuit, il faut l'acheter chez MySQL AB. Si
c'est un truc de boulot tu peux sans doute acquérir cet outil, c'est
beaucoup plus propre, et puis il faut bien qu'ils vivent.

On peut également utiliser la réplication, et sauvegarder la base
répliquée.

Oui répliquer, mais il n'est pas certain que ça revienne moins cher.

Sauf si l'on a des volumes de données énormes, mais dans ce cas là de toute
façon on ne pourra jamais réellement sauvegarder une base énorme qui
travaille beaucoup, dans un cas de ce genre il faut avoir plusieurs
serveurs de réplication, dans des sites différents avec la sécurité qui va
avec et cet ensemble de serveur constitue la sauvegarde.

J'ai eu à sauvegarder des bases de données médicales, avec images de radios
numérisées etc. qui atteignaient il y a déjà quelques années des volumes en
To et la nuit ne suffisait pas à faire la sauvegarde. Donc pas le choix, il
a fallu répliquer. Mais ce n'était pas du MySQL.

Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la
base dans un fichier texte, souvent sous forme d'instructions SQL
d'insert pour pouvoir recréer les bases et y réinjecter les données en
restauration. Beaucoup plus long que de faire un rsync sur une
arborescence à mon goût.

Plus long mais plus fiable. La vitesse est la seule raison pour
laquelle tu n'aime pas dumper ?

La vitesse de restauration entre autre. Comme je n'ai pas utilisé pendant
longtemps sous MySQL de tables autres que MyISAM, mysqlhotcopy et un rsync
dessus a toujours fait l'affaire, et la restauration avec un rsync dans
l'autre sens, c'est le plus rapide et le plus sûr (la copie d'arborescence
est la méthode préconisée avec postgreSQL d'ailleurs quand on peut le
faire).

Qu'est-ce qui te fait dire que ton dump est plus fiable que ma copie
d'arborescence ? Du moment bien entendu que les précautions sont prises
pour soit verrouiller la base soit l'arrêter pour la recopie
d'arborescence ?

D'ailleurs ça me fait penser, je n'ai pas regardé ça de près, mais qu'il me
semble que maintenant sur MySQL on peut avoir des logs binaires qui peuvent
être utilisés en cas de crash de la base. Est-ce que ce type de logs
pourrait être utilisés de façon analogue à un dump ?

Le Wed, 07 Oct 2009 14:02:29 +0000, Bernard a écrit:

Bonjour,

Merci d'avance pour vos conseils et recommandations.

Combien y-a-t'il d'utilisateurs de cette base? Pour tes besoins, as-tu
considéré l'usage de sqlite, plutôt que de mysql?

L'administration en est en effet simplifiée, vu que toute la base tient
dans un seul fichier (relativement portable, donc).

(attention, bien qu'un peu éclairé, je ne suis qu'un amateur en bdd).

@+
--
Yves

Le Thu, 08 Oct 2009 10:31:48 +0200, Alarch a écrit :

Bernard wrote:

Bonjour à tous,

Je précise tout de suite que je débute sur les bases de données, et
que, autre singularité, je ne travaille pas sous MSWIN, mais sous Linux
(Debian Lenny pour mon desktop, Ubuntu Hardy Heron sur mon laptop).

Jusqu'alors, je me contentais de gérer mes bases avec StarCalc
(OpenOffice Calc), tableur voisin de MS EXCEL. Lorsque lesdites bases
ont dépassé 65536 lignes, j'ai dû me résoudre à les fractionner, ce qui
n'est pas génial, surtout lorsqu'on doit faire des tris et autres
opérations.

Alors j'ai essayé OpenOffice BASE avec MySQL, sur les conseils reçus
par les utilisateurs rencontrés sur fr.comp.os.linux.configuration,
lesquels m'ont recommandé de venir ici pour des questions plus
précisément ciblées sur les bases de données.

J'ai donc désormais une serveur mysql, et j'essaye de gérer l'essentiel
via l'interface proposée par OO_Base. C'est un peu lent (3 minutes pour
parcourir une base de 65,000 enregistrements du premier au dernier, 6
minutes pour une base de 115568 enregistrements de 19 champs d'en
moyenne 50 octets CHAR chacun), mais c'est gérable.

Qu'entends-tu par parcourir tes enregistrements ? Juste les afficher à
l'écran ou y effectuer un traitement. Parce qu'en local les temps que tu
annonces me semblent incroyablement longs. Tu n'aurais pas des problèmes
d'index inexistants sur des champs de tri courants ?

Là, je fais référence à des temps constatés lors de l'exploitation d'une
base mysql via OpenOffice.org BASE. Un fichier csv de 65,000 lignes
demande à peu près 3 minutes pour s'intégrer à ma base mysql par copié/
collé. Ensuite je fais l'ajout de la deuxième partie, et çà prend à peu
près le même temps. Par contre, si je fais la manip, non plus via
OO_Base, mais directement sous MySQL, via une ligne de commande que j'ai
adaptée d'après une doc trouvée par Google Search, çà ne prend pas 3
minutes, mais seulement 0.15 sec, comme affiché à la fin du processus.

Revenons à OO Base. Si j'ouvre la table, ce qui s'affiche à l'écran
précise : line 1 of 50. Il n'y a en effet que 50 lignes affichées. Si je
fais 'suite', il s'affiche davantage, mais après 2 ou 3 pression sur la
touche PAGE_DOWN, il y a un délai d'attente avant que ne s'affiche la
suivante. Reste la possibilité de cliquer sur le bouton '>>|' (dernière
fiche). Lorsque je clique là dessus, j'attends environ 3 minutes s'il
s'agit d'une table de 65,000 lignes, environ 6 minutes pour mon fichier
entier (115568 lignes), avant d'arriver à la dernière ligne. Pendant le
temps d'attente, je ne vois rien se passer, le bouton '>>|' a disparu, et
un 'top' dans un terminal m'indique que 99% de la CPU et 60% de la
mémoire sont accaparés par OpenOffice. A la fin du processus, le bouton
réapparaît, et je me retrouve avec un tableau indiquant, non plus 'line 1
of 50', mais 'line 115568 of 115568'. Ensuite, si je clique sur '|<<', le
retour à la ligne 1 est quasiment instantané, idem pour le retour à la
dernière ligne. Et, désormais, au lieu d'afficher 'line 1 of 50', çà
affiche 'line 1 of 115568'. Une fois ce premier parcours achevé, les va
et vient entre la première et la dernière ligne sont quasiment
instantanés.

Le Thu, 08 Oct 2009 10:31:48 +0200, Alarch a écrit:

Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à
un moment de la journée arrêter ta base, alors tu as au moins deux
solutions : faire une recopie avec cp et les options d'archives qui vont
bien (man cp) ou mieux un rsync avec les bonnes options (man rsync), de
/var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).

Si on veut éviter les soucis, cela ne suffit pas.
Il faut aussi sauvegarder les *programmes* et toutes les bibliothèques
utilisées par le SGBDR.
Parce que sinon, le jour où l'on met à jour le moteur, les anciennes
sauvegardes ne seront pas nécessairement compatibles au niveau binaire
(il peut suffire d'avoir un changement dans les options de compilation ou
un passage 32bits vers 64bits pour avoir des données stockées
différements sur le disque) et donc potentiellement inutilisables... sauf
à reinstaller l'ancienne version ce qui peut être plus ou moins simple,
mais en tout cas bien plus rapide si on a pensé à sauvegarder les
programmes et pas seulement les données.

A noter que pour tout projet non trivial, je ne pense pas qu'on puisse
admettre d'arrêter la base, d'autant que ce n'est pas pour un temps court
déterminé genre pour une mise à jour, mais un temps plus ou moins long,
proportionnel à la quantité de données à exporter, temps non connu
d'avance.

Si on veut vraiment ce genre de sauvegardes il vaut mieux :
- soit avoir de la réplication, et comme ca on peut arrêter l'esclave
quand on veut pour faire la sauvegarde à cet endroit
(étant donné que la présence de l'esclave est déjà une sauvegarde en soi,
en tout cas au niveau de la défaillance du serveur principal, pas au
niveau d'un DELETE FROM mal utilisé)
- soit avoir la coopération du SGBDR pour pouvoir faire un snapshot du
système de fichier sans stoper le SGBDR. PostgreSQL permet cela dans les
versions récentes, MySQL je ne sais pas.
Ou utiliser d'autres fonctionnalités d'icelui, si présentes, comme le
"log shipping".

Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la
base dans un fichier texte, souvent sous forme d'instructions SQL
d'insert pour pouvoir recréer les bases et y réinjecter les données en
restauration. Beaucoup plus long que de faire un rsync sur une
arborescence à mon goût.

Cela a cependant l'avantage de fournir un résultat dans un format
"neutre" qui s'affranchit grandement des différences de version du
programme. Par contre il peut se poser, pour certains SGBDRs, un problème
de cohérence des données.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/prices>
<http://icann-registrars-life.dotandco.net/>

Patrick Mevzek wrote:

Le Thu, 08 Oct 2009 10:31:48 +0200, Alarch a écrit:

Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à
un moment de la journée arrêter ta base, alors tu as au moins deux
solutions : faire une recopie avec cp et les options d'archives qui vont
bien (man cp) ou mieux un rsync avec les bonnes options (man rsync), de
/var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).

Si on veut éviter les soucis, cela ne suffit pas.
Il faut aussi sauvegarder les *programmes* et toutes les bibliothèques
utilisées par le SGBDR.
Parce que sinon, le jour où l'on met à jour le moteur, les anciennes
sauvegardes ne seront pas nécessairement compatibles au niveau binaire
(il peut suffire d'avoir un changement dans les options de compilation ou
un passage 32bits vers 64bits pour avoir des données stockées
différements sur le disque) et donc potentiellement inutilisables... sauf
à reinstaller l'ancienne version ce qui peut être plus ou moins simple,
mais en tout cas bien plus rapide si on a pensé à sauvegarder les
programmes et pas seulement les données.

Oui vu ainsi tu as raison, cela ne marche que "à toutes choses égales". Mais
la sauvegarde des exécutables ne se fait q'une fois lors de chaque mise à
jour importante, pas quotidiennement non ?

A noter que pour tout projet non trivial, je ne pense pas qu'on puisse
admettre d'arrêter la base, d'autant que ce n'est pas pour un temps court
déterminé genre pour une mise à jour, mais un temps plus ou moins long,
proportionnel à la quantité de données à exporter, temps non connu
d'avance.

Oui c'est pourquoi les copies à chaud (si elles ne prennent pas plus de
temps que l'intervalle entre sauvegardes souhaitées) ou la réplication sont
presque indispensables.

Si on veut vraiment ce genre de sauvegardes il vaut mieux :
- soit avoir de la réplication, et comme ca on peut arrêter l'esclave
quand on veut pour faire la sauvegarde à cet endroit
(étant donné que la présence de l'esclave est déjà une sauvegarde en soi,
en tout cas au niveau de la défaillance du serveur principal, pas au
niveau d'un DELETE FROM mal utilisé)

Oui cela pose tout de même la question du temps d'arrête de l'esclave et de
tout ce qu'il va devoir "rattrapper après la sauvegarde". Si la sauvegarde
est très longue il faut plusieurs esclaves si l'on veut cumuler redondance
et sauvegarde.

- soit avoir la coopération du SGBDR pour pouvoir faire un snapshot du
système de fichier sans stoper le SGBDR. PostgreSQL permet cela dans les
versions récentes, MySQL je ne sais pas.

Pas à ma connaissance, mais je n'ai pas utilisé de versions très très
récentes. Pour PostgreSQL en effet depuis longtemps il préconisent la
sauvegarde de l'arborescence mais avant ils ne fournissaient pas l'outil
pour faire les snapshot.

Ou utiliser d'autres fonctionnalités d'icelui, si présentes, comme le
"log shipping".

Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la
base dans un fichier texte, souvent sous forme d'instructions SQL
d'insert pour pouvoir recréer les bases et y réinjecter les données en
restauration. Beaucoup plus long que de faire un rsync sur une
arborescence à mon goût.

Cela a cependant l'avantage de fournir un résultat dans un format
"neutre" qui s'affranchit grandement des différences de version du
programme. Par contre il peut se poser, pour certains SGBDRs, un problème
de cohérence des données.

Oui pour ce qui est du format tu touches juste, mais pour de gros volumes de
données j'ai des souvenirs de temps de reconstruction tellement
horriblement longs (non comparable à une restitution d'arborescence,
postulant qu'on restaure l'arbo dans un environnement compatible) que
j'avais un peu mis de côté cette solution.

En fait il ne semble pas y avoir de solution imparable si je te suis bien...
répliction + sauvegarde d'arborescence avec les binaires qui vont bien +
dump si on veut avoir toutes les chances ça fait beaucoup ! Et comme
toujours ce n'est qu'au moment de restaurer qu'on s'apperçoit que rien ne
marche... ;-)