Discussion :

[essence-ciel]

Bonjour,
Afin de ré-indexer/réorganiser ma base de données à partir du programme, en fin de journée de travail, alors que tout les tableaux de saisie sont clos, j'utilise ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
  DataModule1.Connexion.Commit;
  DataModule1.Connexion.ExecSQL('PRAGMA page_size=16384');
  DataModule1.Connexion.ExecSQL('PRAGMA auto_vacuum = true');
  DataModule1.Connexion.ExecSQL('PRAGMA auto_vacuum = INCREMENTAL');
  DataModule1.Connexion.ExecSQL('VACUUM');

or je reçois systématiquement la même erreur : FireDac Phys Sqlite - Cannot Vacuum - Sql statements in progress

Quelqu'un a-t-il déjà rencontré ce problème ? Dans l'affirmative, je suis preneur.
Bonne journée.

[SergioMaster]

Bonjour le caillou.

Bien que je pense que cette question devrait être posée dans Delphi/Base de données à mon avis il faudrait plutôt passer par un TFDScript ou alors mettre des Commit entre chaque ExecSQL.
Question ? Qui dit commit dit base de données ouverte en mode cacheupdate (AMHA avec SQLite c'est inutile)

[essence-ciel]

Bonjour Sergio,
Merci pour ta réponse. Je me suis posé la question du forum... Vaccuum = SQLite, d'où mon choix.

La base de données n'est pas en mode CacheUpDate, j'ai cru comprendre que c'était inutile avec SQLite.

Dans mon idée, Commit était plutôt réservé aux données, non aux règles de la BDD. J'ai testé avec un Commit entre chaque, même message d'erreur. J'ai pensé agir sur une DDD fermée mais il ne me paraît pas logique travailler avec une connexion fermée.

Pour l'utilisation du TFDScript, jamais utilisé ! Je vais tester...

Encore merci.

[SergioMaster]

Bonjour

alors j'ai fait le test du fdscript


button1 lance le script

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
procedure TForm1.Button1Click(Sender: TObject);
begin
fdScript1.ExecuteAll;
end;

pas d'erreur, maintenant comment vérifier que cela a été effectué ?

[SergioMaster]

En continuant à ruminer et chercher dans la doc de Firedac (puisqu'en fin de compte il s'agit de Firedac plus que SQLite)
je découvre le composant FDSQLiteValidate et sa méthode sweep
encore moins fatiguant

[essence-ciel]

Bonjour Sergio,
Désolé pour la tardiveté de ma réponse. Je devais tester le FDScript mais un problème de termites m'a fortement préoccupé et bien occupé. Merci néanmoins pour les pistes proposées.

Je vais tester les 2 solutions avec une BDD ayant eu des mouvements.

[essence-ciel]

Hello Sergio,
Sauf erreur de ma part FDScript.ExecuteAll retourne un résultat booléen, c'est peut-être le moyen de savoir si le Vacuum a été exécuté.
Merci encore, je teste maintenant le Sweep et je garderai ce qui me paraîtra le plus approprié.

[SergioMaster]

Bonjour,

mais un problème de termites m'a fortement préoccupé et bien occupé.

des termites sur un caillou, pas grand chose à se mettre sous la machoire

Sauf erreur de ma part FDScript.ExecuteAll retourne un résultat booléen, c'est peut-être le moyen de savoir si le Vacuum a été exécuté.

que le script a bien été exécuté mais de là à pouvoir écrire que le vacuum est fait ...
Seule un BDD avec des mouvements, comparée (en taille ?) à la même BDD après vacuum pourrait être l'indicateur que le VACUUM à fait quelque chose

[essence-ciel]

Bonjour Sergio,
Pour les termites, on remercie les Américains qui nous les ont laissées en 1942-1943... C'est une véritable plaie !

Comme tu le dits, les deux options sont effectivement exécutées mais pas moyen de savoir si le Vacuum a réellement été effectué. Je comprends de ta réponse qu'il faut charger la taille de la BDD avant l'appel à Vacuum et le comparer après l'appel... Me prenant la tête en ce moment avec des requêtes imbriquées en SQL, je profiterai d'une modification de l'applicatif pour intégrer ça, cela me semble pas trop complexe.
Encore merci pour tes solutions avisées.

[SergioMaster]

Bonjour,

J'ai bien une idée de test : créer une petite base (une table),récupérer la taille du fichier, remplir allègrement celle-ci (par programme) puis effacer (de manière tout aussi "régulière") de façon à remplir plusieurs pages.(tester de temps en temps la taille ?).
En fin de programme récupérer à nouveau la taille , faire le vacuum puis comparer.
Pas dit que je ne vais pas faire ce petit machin histoire dans avoir le coeur net

[Edit] Voilà qui est fait (test avec TFDSQLiteValidate)

cela se passe de commentaire si ce n'est qu'il est dommage d'avoir à mettre un TFDPhysSQLiteDriver (AMHA ce devrait être sous entendu dans TFDSQLiteValidate)
pour info, j'ai utilisé TFile.GetSize(FDConnection1.Params.Database) de l'unité system.ioutils pour la taille.
NB. un test supplémentaire avec FDScript confirme que cela fonctionne également. Par contre cette histoire de auto_vacuum=true ou auto_vacuum=INCREMENTAL (les deux sont possibles ou s'écrase ) je ne vois pas comment vérifier ça


Je ne pense pas que cet exploit "programmistique" ne nécessite pas que je fournisse les sources (enfin je les garde un certains temps, défini par le temps de refroidissement du canon)

[essence-ciel]

Salut SergioMaster,
Je saute d'un problème à l'autre et que je n'ai pas encore testé la vérification des tailles de fichier avant et après le Vacuum... Lorsque l'on est encore en activité, il faudrait des minutes de 90 secondes, des heures de 90 minutes et des journées de 36 heures pour tout explorer !

Quant au TFDPhysSQLiteDriver (il est, à mon humble avis, indispensable avec SQLite) en sus du TFDSQLiteValidate, cela ne m'apparaît pas problématique.

Pour ce qui est des auto_vacuum=true et auto_vacuum=INCREMENTAL, sauf erreur de ma part et d'après ce que je peux lire et (essayer de) comprendre, le premier autoriserait la duplication de la BDD et le second indiquerait le mode de duplication (NONE-FULL-INCREMENTAL) avec réduction ou non de la BDD. J'avoue avoir quelques difficultés à bien discriminer la différence entre les deux. Peut-être convient-il de supprimer une instruction ? Ceci étant, je continue de chercher.

Merci néanmoins pour les pistes, cela m'ouvre des perspectives à explorer.