Perso j'ai quelque peu de mal à y croire, surtout si c'est un portage à coup de find-replace comme cela a été mentionné plus haut. C'est à dire qui ne tire pas du tout parti de la puissance objet et des types disponibles dans le framework.
peut être que le côté 100% managé du code lui donne un avantage sur sql server CE, il y a aussi une chance qu'on l'utilise comme BDD légère sur mobile.
Cependant il faut garder à l'esprit que... c'est SQLite! Donc des outils d'administrations assez bof (à ma connaissance du moins), pas de contraintes de clef étrangères, typage faible etc...
SQL server CE qui est un produit éprouvé, des kilomètres devant SQLite question fonctionnalité et qui dispose de la version gratuite de SQLSMS, c'est déjà une solution intéressante pour pas un rond (à mon avis).
Firebird a l'avantage de pouvoir être upgradé en version serveur très facilement sans toucher au code de l'application.
VistaDb, bien que payant, est une solution 100% managée très supportée qui a beaucoup à faire valoir...
A noter que ces 3 solutions disposent déjà de drivers ADO.net relativement au point (je dis relativement à cause de firebird mais faudrait que je me remette à jour). Donc quel place pour ce SQLite c# au final? Je suppose les petites applications qui veulent stocker quelques données dans un format un minimum structuré, sans trop d'exigences et avec plus de flexibilité que du XML ou des fichiers plats...
Par contre cette syntaxe dégueulasse mentionnée plus haut par Smyley m'inquiète un peu.
Partager