Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
sauvegarde_script_sql [2014/04/08 10:13] tyrtamos |
sauvegarde_script_sql [2014/04/08 10:22] tyrtamos |
||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
- | ====== Sauvegarde | + | ====== Sauvegarde |
- | [en cours de modification le 8/4/2014] | + | [modification le 8/4/2014: refonte complète de la page] |
===== Solution de base ===== | ===== Solution de base ===== | ||
Ligne 164: | Ligne 164: | ||
</ | </ | ||
- | Qui devient: | + | qui devient: |
<code python> | <code python> | ||
Ligne 174: | Ligne 174: | ||
Autre problème, mais cette fois-ci avec cx_freeze pour Python 2.7 (pas de problème avec Python 3): | Autre problème, mais cette fois-ci avec cx_freeze pour Python 2.7 (pas de problème avec Python 3): | ||
- | Alors que sans cx_freeze, les lignes de script retournées par iterdump sont correctement encodées, avec cx_freeze, les caractères accentués des données fournissent des erreurs d' | + | Alors que sans cx_freeze, les lignes de script retournées par "iterdump" |
En fait, alors que les données lues dans les tables sont en unicode, ce n'est pas le cas des lignes de script retournées par iterdump. | En fait, alors que les données lues dans les tables sont en unicode, ce n'est pas le cas des lignes de script retournées par iterdump. | ||
- | La correction est évidente: dans toutes les lignes du fichier dump.py qui contiennent un " | + | La correction est évidente: dans toutes les lignes du fichier dump.py qui contiennent un " |
<code python> | <code python> |