Soit une base (chez l'hebergeur) d'un Spip 1.8.3 faisant 100 Mo coupé en morceau par un petit logiciel impeccable et remis sur une base en localhost..
Impossible à charger erreur SQL
Soit un spip 1.9.3 avec ses tables vides dans la base localhost. Recharge des données de la 1.8.3 vers la 1.9.3 .Echec! Les champs popularite de la table spip_articles ne sont pas admis..d'autres champs ou colonnes de la table spip_auteurs posent pr^blèmes..
Alors la question est: Comment passer une base entière 1.8.3 de 100Mo sur un localhost, je n'ai pas la solution et ma migration semble pas aussi evidente que celà..car ensuite je devrais faire la démarche inverse..
Il faut en fait commencer par installer la même version de SPIP que
celle que tu avais en ligne. Si tu avais 1.8.3, tu réinstalles la
1.8.3 en local.
Puis lorsque c'est fait, tu fais la mise à jour vers la dernière
version de SPIP (1.9.2 ou 1.9.3)... Qui fera les mise à jour de la
base pour qu'elle corresponde à la structure de la 1.9.x...
Le 28/08/07, monnaieancienne<monnaieancienne@free.fr> a écrit :
Soit une base (chez l'hebergeur) d'un Spip 1.8.3 faisant 100 Mo coupé en
morceau par un petit logiciel impeccable et remis sur une base en
localhost..
Impossible à charger erreur SQL
Soit un spip 1.9.3 avec ses tables vides dans la base localhost.
Recharge des données de la 1.8.3 vers la 1.9.3 .Echec! Les champs
popularite de la table spip_articles ne sont pas admis..d'autres champs
ou colonnes de la table spip_auteurs posent pr^blèmes..
Alors la question est: Comment passer une base entière 1.8.3 de 100Mo
sur un localhost, je n'ai pas la solution et ma migration semble pas
aussi evidente que celà..car ensuite je devrais faire la démarche inverse..
Il faut en fait commencer par installer la même version de SPIP que
celle que tu avais en ligne. Si tu avais 1.8.3, tu réinstalles la
1.8.3 en local.
Puis lorsque c'est fait, tu fais la mise à jour vers la dernière
version de SPIP (1.9.2 ou 1.9.3)... Qui fera les mise à jour de la
base pour qu'elle corresponde à la structure de la 1.9.x...
Le 28/08/07, monnaieancienne<monnaieancienne@free.fr> a écrit :
Soit une base (chez l'hebergeur) d'un Spip 1.8.3 faisant 100 Mo coupé en
morceau par un petit logiciel impeccable et remis sur une base en
localhost..
Impossible à charger erreur SQL
Soit un spip 1.9.3 avec ses tables vides dans la base localhost.
Recharge des données de la 1.8.3 vers la 1.9.3 .Echec! Les champs
popularite de la table spip_articles ne sont pas admis..d'autres champs
ou colonnes de la table spip_auteurs posent pr^blèmes..
Alors la question est: Comment passer une base entière 1.8.3 de 100Mo
sur un localhost, je n'ai pas la solution et ma migration semble pas
aussi evidente que celà..car ensuite je devrais faire la démarche inverse..
Oui c'est que je viens de faire en dernier recours et j'obtiens :
Action : restauration de la sauvegarde dump.xml
*Attention ! Le fichier .. / tmp / dump / dump.xml correspond à une autre version de SPIP que celle que vous avez installée.* Vous allez au-devant de grosses difficultés : risque de destruction de votre base de données, dysfonctionnements divers du site, etc. Ne validez pas cette demande d’importation...
Et je mets d'ailleurs aussi le doigt sur L'ENORME faute d'orthographe (et ce n'est pas la seule dans spip) sur Dysfonctionnement ! C'est disfonctionnement..
Oui c'est que je viens de faire en dernier recours et j'obtiens :
Action : restauration de la sauvegarde dump.xml
*Attention ! Le fichier .. / tmp / dump / dump.xml correspond à une autre version de SPIP que celle que vous avez installée.* Vous allez au-devant de grosses difficultés : risque de destruction de votre base de données, dysfonctionnements divers du site, etc. Ne validez pas cette demande d’importation...
Et je mets d'ailleurs aussi le doigt sur L'ENORME faute d'orthographe (et ce n'est pas la seule dans spip) sur Dysfonctionnement ! C'est disfonctionnement..
Oui c'est que je viens de faire en dernier recours et j'obtiens :
Action : restauration de la sauvegarde dump.xml
*Attention ! Le fichier .. / tmp / dump / dump.xml correspond à une autre version de SPIP que celle que vous avez installée.* Vous allez au-devant de grosses difficultés : risque de destruction de votre base de données, dysfonctionnements divers du site, etc. Ne validez pas cette demande d’importation...
Et je mets d'ailleurs aussi le doigt sur L'ENORME faute d'orthographe (et ce n'est pas la seule dans spip) sur Dysfonctionnement ! C'est disfonctionnement..
Dis ou dys les deux orthographes semblent bonnes après vérification mais normallement
/Dis/ signifiant "rupture" en latin, étymologiquement, "rupture de fonctionnement" c'est plus correct
Oui c'est que je viens de faire en dernier recours et j'obtiens :
Action : restauration de la sauvegarde dump.xml
*Attention ! Le fichier .. / tmp / dump / dump.xml correspond à une autre version de SPIP que celle que vous avez installée.* Vous allez au-devant de grosses difficultés : risque de destruction de votre base de données, dysfonctionnements divers du site, etc. Ne validez pas cette demande d’importation...
Bernard
Je reviens sur la question car là y'a un bleme! Je ne peux faire de sauvegarde de la base de la 1.8.3 qui est aux environs de 80 Mo par l'intermediaire de spip et du ftp! Je bloque le serveur et j'ai une erreur 500. Depuis PhpMyAdmin de l'hebergeur, je ne peux que transferer les données en mode txt les zip gzip etc..sont à 0.
Avec un outil qui coupe les bases en plusieurs morecaux j'arrive à peu près à refaire la base sur mon localhost.
( Chose curieuse d'ailleurs les rubriques sont présentes dans la base, mais pas dans l'interfce admin)
Ensuite je n'ai qu'un auteur redacteur au lieu de 353! Par précaution j'avais mis mon profil à id_auteur=0 sachant que j'allais forcé avec un id_auteur 1.
D'où mes deductions peut être trop hatives:
1 On ne peux pas refaire une base de données si elle dépasse un certain poids avec spip ( le fichier .xml.gz ne chargeant plus)
2 On ne peut pas monter un spip 1.9.3 en partant d'une base entière 1.8.3
Et si c'est le cas, il faut passer par la version d'installation soit 1.8.3 et migrer en 1.9.3 ! C'est pas beau puisque le serveur va conserver tout un tas de truc inutiles (fichiers obsolètes )
Par conséquent j'en déduis que spip 1.9.3 n'est pas au point!
Je reviens sur la question car là y'a un bleme! Je ne peux
faire de sauvegarde de la base de la 1.8.3 qui est aux
environs de 80 Mo par l'intermediaire de spip et du ftp!
Ah ben voilà. Tu te mangerais pas un timeout ou un memory limit ?
Je reviens sur la question car là y'a un bleme! Je ne peux faire de sauvegarde de la base de la 1.8.3 qui est aux environs de 80 Mo par l'intermediaire de spip et du ftp!
Ah ben voilà. Tu te mangerais pas un timeout ou un memory limit ?
Ah ben oui! c'est certainement ça, mais alors? Comment contourner ce problème?
Je sais qu'il y a une commande qui permet de lancer le chargement de grosses bases mais je ne la connais pas..
Ah ben oui! c'est certainement ça, mais alors? Comment contourner ce
problème?
Je sais qu'il y a une commande qui permet de lancer le chargement de
grosses bases mais je ne la connais pas..
