Discussion :

[ovni76]

Bonjour,
J'écris de petites applications de gestion de données sous lazarus avec sqlite et je viens de rencontrer un problème résolu mais peut-être pas de la bonne manière.
Je m'explique mon application gère des livres avec sqlite et le composant TSqlite3Dataset version 0.4. J'utilise un datamodule dans lequel j'ai déclaré autant de composant que de tables dans ma base avec leurs datasources
En fin d'application si les tables ont été modifiées je veux réaliser une sauvegarde, je copie la base dans un autre répertoire pour pouvoir la récupérer en cas de problème.
Sous linux et fedora 10 qui est mon système d'exploitation préférentiel pas de problème, mais sous Xp au moment de la commande de copie j'ai un message comme quoi la base n'est pas accessible. Après des recherches et une bonne aide sur le forum de lazarus un constat sous XP la base reste occupée en mémoire ce qui bloque la copie. Je le redis pas sous linux.
Donc j'ai ajouté une commande data.free avant la commande de copie, data étant le nom de mon datamodule.
Est-ce la bonne solution et pourquoi pas sous linux ?
Merci d'avance

[bigane]

Bonjour,

Je n'ai pas vraiment de réponse à tes questions, juste quelques pistes.

Selon la documentation ( http://www.sqlite.org/c3ref/backup_finish.html )

If sqlite3_backup_step() cannot obtain a required file-system lock, then the busy-handler function is invoked (if one is specified). If the busy-handler returns non-zero before the lock is available, then SQLITE_BUSY is returned to the caller. In this case the call to sqlite3_backup_step() can be retried later. If the source database connection is being used to write to the source database when sqlite3_backup_step() is called, then SQLITE_LOCKED is returned immediately.

En gros, cela donne une erreur SQLITE_BUSY si la routine ne peut établir un verrou sur la base source, ou SQLITE_LOCKED si une page de la base est utilisée en écriture lors de la sauvegarde.

D'après ta description de l'erreur, on peut supposer que la base reste ouverte sous XP tant qu'il existe un datasource non libéré. Quant je parle d' "ouverte" je veux dire qu'un handle de fichier en lecture/écriture est encore actif. Ainsi une demande de verrou (file-system lock) sur la base ne peut être obtenu.
Difficile de dire si cette explication est la bonne, mais elle colle bien à la description du problème.
Pourquoi sous XP et pas sous Linux ? C'est surement à cause des qualités du système de fichiers de Linux qui est, on le sait tous, nettement plus souple et performant que celui de Windows (et pas forcément plus récent). Mais là encore, rien n'est prouvé. Il faut également considéré que sous Linux on utilise un fichier xxx.so alors que l'on a un xxx.dll sous Windows. Il peut donc y avoir quelques différences sur les modes de fonctionnement de ces deux librairies (humm... à prouver).

Maintenant, la solution de libérer le module est elle la bonne ?
Elle a un mérite : c'est de fonctionner sur les deux systèmes. Par contre, elle perd tout l'intérêt de la fonction de backup. En effet, celle-ci a été conçue pour effectuer une sauvegarde "à chaud" de la base. Normalement, il est possible de sauvegarder sur une base ouverte avec des accès en lecture/écriture. Lorsque l'on rencontre des SQLITE_BUSY, il suffit de patienter et de retenter sa chance un peu plus tard.
Je pense donc qu'un data.free est un peut expéditif et qu'il faudrait trouver une solution plus soft au problème.

Par exemple, il y a des propriétés "SaveOnClose" et "SaveOnRefetch" dans le TSqlite3DataSet. Le problème vient peut être de leur positionnement à True dans l'un des composants... Et que dire de la propriété "Active" ?

Bref, si tu as le temps, il y a peut-être des pistes à suivre ; sinon, la solution brute est la bonne.

a+

[ovni76]

Merci pour tes réponses,
Je ferais des essais et je donnerais mes résultats.
A+