Après avoir lancé une sauvegarde, le sablier continue à tourner alors que la sauvegarde est terminée.
==> mettre un message indiquant la fin de la sauvegarde
==> prévoir une restauration des données à partir d'une sauvegarde
A la fin de la sauvegarde, le sablier n'est plus affiché. On repropose l'écran du menu des données initiales. On n'a pas mis de message car celui de téléchargement du fichier de sauvegarde semble suffisant.
Pour la récupération des données, le logiciel n'est pas encore écrit.
Pour l'instant, cela peut se faire avec un utilitaire inclus dans universal Server qui s'appelle phpmyadmin.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Conditions initiales:
Après sauvegarde de la base de données des cloux, importation dans la base locale par phpmyadmin,
Résultat:
l'importation est considérée comme réussie par phpmyadmin.
Quand on lance l'appli locale, tout est bien importé sauf la liste des équipes.
Mais elles existent car par les personnes on remonte à l'équipe dans laquelle cette personne est inscrite.
Attendu :
Que les équipes importées soient affichées dans la liste des équipes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Constat :
La restauration des données fonctionne bien pour des "petites" base de données. Si la bdd est importante (plus de 1000 enregistrements dans certaines tables, mais le nombre n'est pas précis), la restauration est avortée et n'est pas effectuée. On est obligé de passer par phpmyadmin ce qui n'est pas à la portée des utilisateurs. Solution provisoire:
Une solution a été trouvée qui consiste à "saucissonner" les tables de plus de 1000 enregistrements avec l'éditeur "notepad++" : on recopie l'instruction "insert..." de départ tous les 1000 enregistrements. Cela doit être fait pour toutes les tables qui comportent plus de 1000 enregistrements. Résultat attendu :
Que le saucissonnage soit intégré dans la fonction de Restauration ou qu'une autre solution permette la restauration.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Valeur à essayer pour le time : 120 sec.
max_execution_time = 120
Le upload_max_filesize parait suffisant. Il peut être vérifié en regardant la taille de la base de donnée exportée.
(Le php_value correspondait à un copier/coller intempestif, il est de fait à oublier !)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Essai fait avec bdd de tailles successives sur ordinateur Dell6520 avec max_execution_time = 120 secondes
bdd 2515 ko : 50 secondes : OK
bdd 3451 ko : 40 s : OK
bdd 4272 ko : 15 s : NOK
Avec max_execution_time = 240
bdd 4272 ko : 15s : NOK Cette base est une des plus grosses que je connaisse; elle comprend environ 6000 personnes et 3400 foyers. MAIS elle n'est pas restaurée ...
Je ferai un autre essai sur une autre machine
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Essai fait sur ordinateur HP Pavilion w10 peu rapide. Surprise : sur cette machine, le paramètre max_execution_time est à 600 secondes !!! Je ne sais pas comment cette valeur a été mise (je ne me souviens pas de l'avoir modifiée...)
bdd 1886 ko : 10s : ok
bdd 2517 ko : 12s : ok
bdd 3994 ko : 15s : ok
bdd 4272 ko : 3s : NOK : restauration non effectuée
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Comme visible dans CleanParo2.png, l'import de la BD sql se fait dans le fichier Class par la commande system MySQL Cli.
Un exemple de commande est donné sur CleanParo3.png, et c'est cette commande qui n'est pas exécutée lorsque la restauration, bien que non effectuée, n'envoie pas de message d'erreur.
(La différence des système d'exploitation entre en jeux lorsqu'il s'agit des commandes système, il y a potentiellement là une source d'erreur mais cette situation a l'air correctement gérée.)
Pour solutionner, notre proposition :
=> Ecrire un code PHP (fonction ou suite d'instructions) permettant l'import du SQL dans la base actuelle.
A la fin de la sauvegarde, le sablier n'est plus affiché. On repropose l'écran du menu des données initiales. On n'a pas mis de message car celui de téléchargement du fichier de sauvegarde semble suffisant.
Pour la récupération des données, le logiciel n'est pas encore écrit.
Pour l'instant, cela peut se faire avec un utilitaire inclus dans universal Server qui s'appelle phpmyadmin.
Conditions initiales:
Après sauvegarde de la base de données des cloux, importation dans la base locale par phpmyadmin,
Résultat:
l'importation est considérée comme réussie par phpmyadmin.
Quand on lance l'appli locale, tout est bien importé sauf la liste des équipes.
Mais elles existent car par les personnes on remonte à l'équipe dans laquelle cette personne est inscrite.
Attendu :
Que les équipes importées soient affichées dans la liste des équipes.
Constat :
La restauration des données fonctionne bien pour des "petites" base de données. Si la bdd est importante (plus de 1000 enregistrements dans certaines tables, mais le nombre n'est pas précis), la restauration est avortée et n'est pas effectuée. On est obligé de passer par phpmyadmin ce qui n'est pas à la portée des utilisateurs.
Solution provisoire:
Une solution a été trouvée qui consiste à "saucissonner" les tables de plus de 1000 enregistrements avec l'éditeur "notepad++" : on recopie l'instruction "insert..." de départ tous les 1000 enregistrements. Cela doit être fait pour toutes les tables qui comportent plus de 1000 enregistrements.
Résultat attendu :
Que le saucissonnage soit intégré dans la fonction de Restauration ou qu'une autre solution permette la restauration.
Peut-on connaitre les valeurs de
dans les php.ini ?
Dans le fichier : c:\uniserver\usr\local\php
max_execution_time = 30
upload_max_filesize = 10M
L'instruction : php_value n'est pas dans le fichier php.ini
Valeur à essayer pour le time : 120 sec.
max_execution_time = 120
Le upload_max_filesize parait suffisant. Il peut être vérifié en regardant la taille de la base de donnée exportée.
(Le php_value correspondait à un copier/coller intempestif, il est de fait à oublier !)
Essai fait avec bdd de tailles successives sur ordinateur Dell6520 avec max_execution_time = 120 secondes
bdd 2515 ko : 50 secondes : OK
bdd 3451 ko : 40 s : OK
bdd 4272 ko : 15 s : NOK
Avec max_execution_time = 240
bdd 4272 ko : 15s : NOK Cette base est une des plus grosses que je connaisse; elle comprend environ 6000 personnes et 3400 foyers. MAIS elle n'est pas restaurée ...
Je ferai un autre essai sur une autre machine
Essai fait sur ordinateur HP Pavilion w10 peu rapide. Surprise : sur cette machine, le paramètre max_execution_time est à 600 secondes !!! Je ne sais pas comment cette valeur a été mise (je ne me souviens pas de l'avoir modifiée...)
bdd 1886 ko : 10s : ok
bdd 2517 ko : 12s : ok
bdd 3994 ko : 15s : ok
bdd 4272 ko : 3s : NOK : restauration non effectuée
A vérifier avec la base de contrôle reçue
Les fichiers clés sont :
Comme visible dans CleanParo2.png, l'import de la BD sql se fait dans le fichier Class par la commande system MySQL Cli.
Un exemple de commande est donné sur CleanParo3.png, et c'est cette commande qui n'est pas exécutée lorsque la restauration, bien que non effectuée, n'envoie pas de message d'erreur.
(La différence des système d'exploitation entre en jeux lorsqu'il s'agit des commandes système, il y a potentiellement là une source d'erreur mais cette situation a l'air correctement gérée.)
Pour solutionner, notre proposition :
=> Ecrire un code PHP (fonction ou suite d'instructions) permettant l'import du SQL dans la base actuelle.