La command FMDB executeUpdate DROP arrête l'application

Je veux déposer une table dans mon file de database SQLite nommé database.db. Après avoir utilisé

NSLog(@"i show up in the console"); [db executeUpdate:@"DROP TABLE IF EXISTS `article`;"]; NSLog(@"i will not show up in the console"); 

l'application s'arrête à la position de la requête. NSLog avant que la requête ne soit affichée dans la console. NSlog directement après la requête n'apparaît pas dans la window de la console. De plus, un file temporaire appelé database.db-journal est créé et supprimé en permanence dans le dossier de l'application de simulation pendant que l'application est en cours d'exécution. L'application ne plante PAS, ne donne aucune erreur et ne continue pas … Supprimer "IF EXISTS" dans la requête ne fonctionne pas, la suppression des guillemets ne fonctionne pas, la suppression des points-virgules ne fonctionne pas.
Activer le suivi de la requête montre seulement que FMDB traite ma requête, rien de plus n'apparaît.

Je suis vraiment confus pourquoi cela arrive. Je pensais que la table devait être vide avant de pouvoir être abandonnée et j'ai donc ajouté une requête pour supprimer tous les loggings. Mais id n'a pas d'importance, l'application est toujours attrapée à la drop-query. Je manque de possibilités pour résoudre cette erreur.
Si j'exécute la command drop dans SQLite Database Browser 2, tout fonctionne correctement.

D'autres searchs avec le débogueur ont montré que l'encapsuleur FMDB est en boucle infinie car la valeur de return de l'instruction est égale à la constante SQLITE_LOCKED ce qui signifie que la table que je veux déposer est verrouillée. L'envoi de "UNLOCK TABLES" dans une requête précédente ne résout pas cela. Pourquoi la table est-elle verrouillée? Pourquoi supprimer des loggings d'une table verrouillée fonctionnera?

J'ai eu le même problème, et l'ai résolu en appelant closeOpenResultSets sur l'instance FMDB juste avant la mise à jour, comme TRD l'a dit (bien que je n'ai pas eu à fermer et à rouvrir complètement la database)

Je me suis finalement débarrassé de ce comportement désagréable. J'ai fermé la connection à la database juste avant la requête de suppression et l'ai rouverte immédiatement. Si je dois deviner je dirais que SELECT-Requêtes dans les parties antérieures de mon code source fait la connection à être verrouillé pour les déclarations DROP. Ainsi, la fermeture de la connection à la database et sa réouverture réinitialisent ces verrous. J'espère que cela peut vous aider @JLoewy.