J’étais en train d’importer un important volume de photos (en mode « Ajouter à la bibliothèque ») quand il s’est probablement produit une coupure de courant. Depuis Darktable refuse de s’ouvrir ; plus exactement il s’ouvre et se referme immédiatement. Le logiciel ne semble pas en cause, car il fonctionne bien si je le lance avec un autre dossier utilisateur. J’en déduis que ma base de données est corrompue. Y a-t-il un moyen de rétablir son intégrité ou faut-il que je recommence tout (il y en a pour plusieurs jours !)
Précision : je ne trouve pas de fichier library.db.lock ou data.db.lock dans le dossier utilisateur (voir capture) et les éléments masqués sont bien affichés (je suis sous Windows 10)
Bonjour @jonas0_13
Tu devrais essayer de lancer Darktable avec l’option debug (-d common). Peut-être auras-tu plus d’éléments.
Ensuite, malheureusement on ne voit pas de versions précédentes dans ce que tu nous montres, des data ou library.db-snp-yyyymmaahhmmss
Ce qui veut dire que, peut-être tu n’avais pas fermé Darktable avant la coupure de jus ? Ou peut-être aussi que Préférences > Stockage > Base de données > Nombre de sauvegardes à conserver est à 0 ? (déf. 10)
Il te reste à espérer que tu n’as pas fait trop d’import depuis le base de données avant l’install de la 5.6.1. Sinon, si tu connais le SQl : 5 meilleurs clients gratuits pour la base de données MS SQL Server en 2025
sinon Jean Pierre peut peut-être d’aider.
Ce n’est pas une BdD MS SQL !
c’est une base de données SQLITE.
C’est vrai Jean-Pierre, je suis un peu à côté de la plaque, mais il me semble que les outils SQL meuvent aussi l’ouvrir ?
Il est possible de vérifier une BdD Sqlite avec l’outil en ligne de commande sqlite3, ou avec un outil en UI graphique : sqlitebrowser.
Mais j’ignore si ces outils fonctionnent sous Windows.
J’ai regardé ton lien, aucun des outils proposés n’ouvre spécifiquement des bases Sqlite. Les outils génériques font du SQL uniquement et ne peuvent pas intervenir sur la structure de BdD.
Merci de le préciser.
Sqlitebrowser (DB Browser for SQLite) fonctionne sous Windows : Downloads - DB Browser for SQLite
Attention !!! Avec ça tu peux tout casser ! Si tu veux, je peux faire un pilotage en DM
Je ne sais pas ce que c’est ce dossier ? Peut-être voir si un dossier darktable existe ou a été renommé ?
Ma question était adressée à @jonas0_13. ![]()
Waouh ! Quelle réactivité ![]()
Merci à tous pour vos réponses. Je vais lire cela au calme et en faire bon usage. Pour répondre à la question de manu : j’ai conservé par prudence une version antérieure du dossier utilisateur que j’ai rebaptisée _Darktable_md-20261009 ; du coup j’ai appelé la nouvelle version _Darktable_md-20261010. C’est peut-être la cause de mes soucis. Je vérifie et je vous tiens au courant.
PS : vous devez vous demander pourquoi je reconstruis une base de données, alors que j’en avais une. L’explication est que mes photos sont répliquées sur 2 NAS distants : un chez moi, l’autre à la campagne. J’ai voulu utiliser Darktable à la campagne en faisant « pointer » la base de donnée DT sur le NAS « campagne ». Je m’y suis mal pris et cela a mis un bazar pas possible dans le mode « dossiers » des collections dans la table lumineuse. J’ai renoncé à corriger à la main, car c’est extrêmement long, et j’ai décidé de créer une nouvelle base en partant de zéro.
Bilan de mes essais.
« _Darktable_md-20261010 » est simplement mon nouveau dossier utilisateur. Vérification faite, on peut donner n’importe quel nom au dossier utilisateur, lorsqu’on n’utilise pas le dossier standard et qu’on lance DT avec la commande « darktable --configdir %chemin%\nom_du_fichier_utilisateur »
Voici le contenu du fichier log :
version: darktable 5.6.1
start: 2026-10-13 00:27:46
0.6684 [init] database `D:_Michel_Data_Darktable_md-20261010\data.db’ couldn’t be opened. aborting
0.6687 ERROR : cannot open database
C’est normal puisque j’ai créé un nouveau dossier utilisateur « _Darktable_md-20261010 » pour être certain de partir sur une base saine. Les versions antérieures se trouvent dans mon ancien dossier utilisateur « _Darktable_md-20261009 » :
Ca c’est sûr ; la coupure a eu lieu pendant l’importation. DT était actif.
Hélas je ne maîtrise pas sql ni sqlite.
J’ai installé DB Browser et ouvert la base de données « data.db » sans difficulté ; en revanche lorsque j’essaye d’ouvrir « library.db », j’obtiens le message d’erreur :
Cela semble confirmer que la BdD est corrompue. Est-il possible de rétablir son intégrité ?
Encore merci beaucoup à vous tous ![]()
Bonjour,
Tu ne veux pas tout simplement repartir de l’un de tes instantanés (fichiers snapshots) s’ils sont antérieurs à ton mic-mac sur NAS ?.. L’un date du 08/10 à peine et l’autre de fin septembre.
Par contre, je ne suis vraiment pas sûr que l’origine soit une coutpure de courant. Dans ton premier post, le fichier library.db est horodaté à 19:01 alors que 8 minutes plus tard le PC écrivait encore dans data.db…
(ou alors tu as relancé DT entre temps ?)
Bonjour, merci pour toutes tes réponses @jonas0_13 !
Le log 0.6684 [init] database D:_Michel_Data_Darktable_md-20261010\***data.db*** **couldn’t be opened**. aborting et l’ouverture en erreur de library.db via SQLite sont clairs, ces deux .db ne sont pas conformes.
Je ferais comme le propose @FB33, repartir des derniers snapshots du dossier précédent, en les recopiant dans le nouveau dossier et en les y renommant data.db et library.db.
Bonjour,
Je réponds un peu à côté : utiliser la même base de données avec plusieurs sources identiques (ou quasi) est possible, mais pour ça il faut que les chemins soient identiques.
Dans le cas de tes NAS, je ne sais pas comment tu y accèdes, moi je me suis arrangé (un NAS sur un ordinateur et un disque externe synchronisé sur un autre) pour qu’ils aient la même structure et qu’ils se montent sur la même lettre sous Windows (ce qui est facile avec un disque externe crypté avec veracrypt, qui demande sur quelle lettre monter le volume).
Si ce n’est pas possible, alors il faut manipuler un minimum de sql (ce que je fais maintenant entre mon ordi Windows et mon ordi Linux) pour mettre à jour les chemins quand tu passes d’un NAS à l’autre.
Si tu veux creuser ces points, quand tu auras résolu ton problème de fichier corrompu, ouvre un nouveau sujet.
Sébastien
PS : perso j’utilise SQLiteStudio (qui semble être renommé Letos) sous Linux et sous Windows
Effectivement, comme le suggère @Seb17, si la structure de fichiers est la même sur les deux NAS et que c’est juste un problème de « pointage » de la racine… alors une simple requête SQL basée sur REPLACE exécutée sur la table « film_rolls » de library.db devrait te permettre de ré-adresser toutes les collections de ta sauvegarde snapshot au bons endroits (mais je ne suis pas certain d’avoir bien compris ce que tu as fait exactement au cours ton weekend à la campagne !
)
Attention à toutes ces manips directes sur la base, et en tout cas sans en avoir fait une copie de sauvegarde avant tout !
Pour revenir à cette histoire de dossiers de config, bien sûr on peut jouer sur --configdir mais comme on le voit, ce n’est pas aussi simple.
Je conseillerais de toujours conserver le nom du dossier de config en tant que darktable (ou tout autre nom qui demeure inchangé).
Et quand on a besoin d’en créer une nouvelle version d’archive, elle sera renommée comme on veut, mais plus utilisée avec un --configdir, à moins de renommer le dossier darktable en autre chose, puis la version archive en darktable.
Exemple d’utilisation personnelle de --configdir : j’utilise deux versions de Darktable : la stable et la master. Chacune à son dossier de config propre. Pour la master, j’utilise --configdir pour pointer sur le dossier darktable-master.



