Si un problème est détecté sur une base, il va falloir couper son accès. Il convient donc de prévenir les utilisateurs de la maintenance (téléphone, newsletters…)
On ne travaille jamais sur les bases directement.
Si vous n'aviez pas décrypté la base lors de l'étape de sauvegarde, vous pouvez le faire via l'utilitaire en récupérant la clef dans la base de cryptage. A partir de là on travaille sur la base décryptée
Dans un premier temps on travaille de préférence avec SynDBExplorer
| Lancer la commande | PRAGMA integrity_check; | Le traitement peut être long sur de grosses bases La réponse “correcte” est OK Dans le cas contraire on peut tenter une commande de réindexation et réessayer |
| Lancer la commande | REINDEX; | Le traitement peut aussi être long sur de grosses bases S'il n'y a pas d'erreur, la commande ne répond rien (fin de changement du curseur) |
Utilisez l'utilitaire sqlite3 en ligne de commande. La commande .recover est disponible depuis la version 3.29.0 et est plus robuste que .dump. Si .recover n'est pas disponible, utilisez l'ancienne méthode :
sqlite3 base_corrompue.s3dbBrut ".dump" > reparation.sql
Reconstruction de la base. Une fois le fichier SQL généré, injectez-le dans un nouveau fichier de base de données.
| On peut lancer sans danger la commande | Drop Table TableDeleted; |
| On ne peut pas effacer la piste d'audit, mais on peut | 1. L'enregistrer à côté de la base Pour ce faire, enregistrer la piste en entier au format csv Repérer l'ID d'une piste ayant disons 3 ans Effacer Delete from PisteAudit Where ID<?????
|
Après avoir remis la base en ligne, on ne laisse que le fichier de la piste d'audit avec la date de sauvegarde.
On efface les autres fichiers afin de ne pas amplifier les sauvegardes.
On garde sur son poste les versions de travail quelques jours en attente de vérification du client
On indique au client :