Je reçois cette erreur lorsque j'essaie d'exécuter une requête de mise à jour sur une base de données SQLite. Cela n'arrive que sur XP (sur Vista fonctionne très bien). La base de données est créée sans aucun problème, l'insertion fonctionne également bien. J'ai également vérifié et j'ai des autorisations et de l'espace disque disponible (car sqlite.org dit que ce sont des causes possibles).Message d'exception: Une erreur d'E/S de disque s'est produite.
Une réponse qui a fonctionné pour moi est d'utiliser l'instruction PRAGMA pour définir la valeur de journal_mode sur autre chose que "DELETE". Vous le faites en émettant une instruction PRAGMA telle que PRAGMA journal_mode = OFF de la même manière que vous émettez une instruction de requête. J'ai posté un exemple en utilisant C# à: http://www.stevemcarthur.co.uk/blog/post/some-kind-of-disk-io-error-occurred-sqlite/
Modifier
probablement une meilleure déclaration PRAGMA à émettre est PRAGMA journal_mode = TRUNCATE plutôt que « OFF » en tant que deux autres ont suggéré.
par http://www.sqlite.org/pragma.html#pragma_journal_mode (Souligné par):
Le mode OFF désactive complètement le journaling journal de restauration. Aucun journal de restauration n'est jamais créé et, par conséquent, il n'y a jamais de journal de restauration à supprimer. Le mode de journalisation OFF désactive les capacités de validation atomique et de restauration de SQLite. La commande ROLLBACK ne fonctionne plus; il se comporte d'une manière indéfinie. Les applications doivent éviter d'utiliser la commande ROLLBACK lorsque le mode journal est désactivé. Si l'application tombe en panne au milieu d'une transaction lorsque le mode de journalisation OFF est défini, le fichier de base de données sera très probablement corrompu.
On dirait que vous êtes sur la bonne voie, mais l'une des autres options serait plus sûre.
Avez-vous un fichier .db-journal à côté du fichier de base de données? Si c'est le cas, assurez-vous que votre application peut supprimer les fichiers du dossier où se trouve la base de données.
Vos symptômes indiquent que SQLite peut lire et écrire mais ne peut pas supprimer le fichier journal.
Wow, je pense que c'est en fait mon problème ... sur Windows 10 sous le WSL avec un dossier dans dropbox, je pense que Windows empêche SQLite d'accéder à son propre journal car dropbox l'a ouvert pour la synchronisation! – Michael
C'est exactement ma situation. J'ai mis en pause la synchronisation Dropbox et maintenant j'écris des tonnes à la base de données sans problème. Merci. – Marnee
Une autre possibilité serait d'utiliser l'instruction SQL suivante
"PRAGMA journal_mode = TRUNCATE"
Il conserve encore la revue, si la panne de courant au cours d'une transaction que vous êtes toujours en mesure de restaurer et vous éviter la corruption de base de données. La différence entre DELETE et TRUNCATE est que la suppression crée et supprime constamment le fichier journal pour chaque instruction. Truncate a seulement besoin de le créer une fois et il suffit de l'écraser. Dans mon cas c'était beaucoup plus rapide et j'ai évité les permissions bizarres qui viennent avec le standard journal_mode = DELETE.
S'il vous plaît se référer à SQlite3 Pragma_journal_mode explenation
Cette ressemblait la solution parfaite à ce que je cherchais, mais il se avère que d'essayer d'exécuter ce PRAGMA lance la même exception. : D – Trejkaz