Discussion :

[ddaime]

Désolé pour la faute de frappe (Linq et non pas Link). Je confirme que Linq To SQL peu trés bien s'utiliser avec SQL Server CE 3.5 puisque je l'utilise dans un de mes programmes, en revanche le designer de Visual Studio 2008 ne prend pas encore en charge le fournisseur de données SQL Server CE du coup il faut utiliser l'outil SQLMetal.exe en ligne de commande afin de générer le fichier .dbml puis de l'inclure dans le projet.

[ClaudeBg]

Salut
-----

Il faut dire que tu ne te facilites pas les choses... Linq c'est très bien, mais ça suppose quand même d'avoir quelques notions sur les bases de données

J'avais les notions de base, mais ça doit faire 20 ans que je n'ai pas manipulé de bases de données (excepté un peu avec mysql, mais de façon simple). Bref, je sais ce qu'est une clé simple ou composée, une contrainte d'intégrité, une relation n vers m, etc. Ce que je voyais moins bien c'est la façon d'utiliser ça à partir de C#.

En fait, le problème c'était surtout d'accrocher le bon fil de départ pour l'apprentissage sous C#.

Avec tes explications et tes liens, ça commence à être plus clair.

Je vais utiliser sqlite, et créer mes tables par requêtes sql. Ensuite je verrai si je peux profiter de la syntaxe linq sur les tables créées.

Pour l'instant, je pense avoir assez de renseignements théoriques. Je vais maintenant créer des bouts de programmes pour voir comment mettre tout ça en place. Ca devrait devenir plus clair en pratiquant, car je verrais ce qui est possible ou non, et comment ça le sera.

Merci 1000 fois

Claude

[WOLO Laurent]

Je vais essayer de te résumer la situation :

Si tu ne veux pas te compliquer la situation avec un serveur vu l'intérêt de programme, utilise access ou SQLLite ou .... mais il faut que tu saches que tu perds des avantages comme les procedures stockées, triggers, les transactions ...
Et tu as toujours la possibilité d'utiliser Linq to SQL ...
Si tu utilises tes fichiers binaires (tu reparts au bon vieux temps et c'est une perte de temps parce que tu réinventes la roue), tu pourras toujours les charger dans une collection et faire des requête Link to Entities mais là aussi, pour que tu t'en sortes, il te faut une petite plongé dans le monde des SGBDR Modernes .

La balle est dans ton camps

[tomlev]

mais il faut que tu saches que tu perds des avantages comme les procedures stockées, triggers, les transactions ...

Pas forcément... SQLite offre un support basique pour les triggers, et il est même possible d'utiliser dans les requêtes SQL des fonctions définies en C#. Ce n'est pas tout à fait comme des procédures stockées mais c'est déjà pas mal

Si tu utilises tes fichiers binaires (tu reparts au bon vieux temps et c'est une perte de temps parce que tu réinventes la roue), tu pourras toujours les charger dans une collection et faire des requête Link to Entities

Euh... Linq to Objects tu veux dire ? Pour Linq to Entities il faut un provider ADO.NET qui le supporte

[ClaudeBg]

Bonjour,

et merci

Avec une application aussi basique, je peux parfaitement me passer de triggers, il n'y a du reste pas vraiment d'actions en entraînant d'autres.

Pareil pour les procédures stockées, si j'ai bien compris le principe, vu qu'il n'y aura aucun autre programme utilisant la BDD.

J'ai fait des essais avec SQLITE, et j'ai pu créer et manipuler une base (SQLiteConnectionStringBuilder etc). Par contre, ça reste assez éloigné du concept objet, et en plus j'ai été contraint d'utiliser des champs de longueur fixe (ça me ramène en arrière), ce à quoi je voulais échapper, ainsi qu'utiliser des requêtes SQL contrôlées à l'exécution et non à la compilation.

J'ai par contre vu qu'il y avait maintenant inclus le "linq to sqlite", je vais maintenant voir comment on met ça en place, ça ressemble à première vue à linq to sql, tout en n'ayant évidemment plus besoin du serveur (le beurre et l'argent du beurre).

Le coup de la collection en RAM, j'y avais pensé dès le départ, ça semble assez simple avec linq to objects, mais ça ne présente pas que des avantages.

En tout cas, je vois maintenant beaucoup mieux les différentes possibilités, et sqlite me semble le meilleur compromis sur une machine où on ne désire pas installer un serveur, ni acheter d'applications commerciales spécifiques. Me reste à échapper aux champs de longueur fixe.

Merci
Claude

[tomlev]

J'ai par contre vu qu'il y avait maintenant inclus le "linq to sqlite", je vais maintenant voir comment on met ça en place, ça ressemble à première vue à linq to sql, tout en n'ayant évidemment plus besoin du serveur (le beurre et l'argent du beurre).

Jamais entendu parler de Linq to SQLite... par contre, comme je l'ai dit plus haut, tu peux utiliser Linq to Entities avec SQLite, le provider dont j'ai donné le lien l'implémente correctement (je l'utilise déjà dans une application). Il suffit d'ajouter à ton projet un "ADO.NET Entity Data Model", de sélectionner ta base de données, et de choisir les tables que tu veux importer. Le wizard génèrera automatiquement le modèle objet, que tu pourras personnaliser ensuite (modifier les noms des classes et propriétés par exemple)

[ClaudeBg]

Salut
-----

Jamais entendu parler de Linq to SQLite

Ben, je suis tombé ici dans mes recherches :

http://devart.com/dotconnect/sqlite/features.html

(voir le 7ème titre : Linq to SQLite)

J'ai installé ceci :

http://sqlite.phxsoftware.com/

Dans les références de mon projet, j'ai accès à :

System.data.sqlite
et à
System.data.sqlite.linq

Il suffit d'ajouter à ton projet un "ADO.NET Entity Data Model", de sélectionner ta base de données, et de choisir les tables que tu veux importer. Le wizard génèrera automatiquement le modèle objet, que tu pourras personnaliser ensuite (modifier les noms des classes et propriétés par exemple)

J'expérimente tout ça.

Merci
Claude

[WOLO Laurent]

Pas forcément... SQLite offre un support basique pour les triggers, et il est même possible d'utiliser dans les requêtes SQL des fonctions définies en C#. Ce n'est pas tout à fait comme des procédures stockées mais c'est déjà pas mal

Je voulais par cette même occasion lui donner la difference entre un SGBD Client/serveur et un SGBDR fichier.
Heureusement que tu te rattrappes en disons qu'il supporte (SQLLite) les triggers de façons basique.
En outre, étant donné qu'il est serverless, je ne crois pas qu'il puisse intégrer des fonctionnalités intérrescentes qui ont fait le succes de SQL Serveur et Oracle.
L'auteur dit qu'il faut penser à SQLLite comme un remplacement de fopen mais pas d'Oracle et je pense qu'il est assez clair.

Quand au procédure stockée, tu ne va pas comparer l'intérêt d'une procedure stockée à un code client même écrit en C#

[tomlev]

Ben, je suis tombé ici dans mes recherches :

http://devart.com/dotconnect/sqlite/features.html

(voir le 7ème titre : Linq to SQLite)

Ah ok... c'est une implémentation de Linq to Entities ET de Linq to SQL (d'ailleurs je pensais pas que c'était possible) pour SQLite. Mais c'est payant il me semble... alors que System.Data.SQLite est gratuit

[ClaudeBg]

Salut
-----

Ah ok... c'est une implémentation de Linq to Entities ET de Linq to SQL (d'ailleurs je pensais pas que c'était possible) pour SQLite. Mais c'est payant il me semble... alors que System.Data.SQLite est gratuit

Il y a une version gratuite.

Mais de toutes façons, je viens d'utiliser, comme conseillé, linq to entities sur sqlite, et ça fonctionne très bien. Je n'ai pas rencontré jusqu'à présent de difficultés particulières, mise à part celle-ci :

Lors de la réalisation du modèle, on établit le lien avec la base de données.
Donc, le nom de la base est codé "en dur" dans le programme.
En fait, je l'ai trouvé dans le fichier app.config , c'est un fichier xml.

Or, j'ai besoin de pouvoir pointer sur un autre fichier dynamiquement dans le programme, parce que d'une part l'utilisateur utilise deux facturiers distincts (mais de structures identiques), et que d'autre part il va se balader occasionnellement avec son facturier sur un support mobile, et qu'il se peut que la lettre du lecteur change.

Comment fait-on pour changer la base cible "au vol"?

J'ai constaté que ça semblait fonctionner sur un mode déconnecté, puisqu'on peut changer le nom de la base sur le disque (pas de verrou), et que le programme ne s'en aperçoit que sur la prochaine exécution de requête.

J'ai tenté de modifier le nom directement dans le fichier app.config, en dynamique, mais il n'est pris en compte qu'au prochain redémarrage du programme : pas pratique ni élégant de demander à l'utilisateur de redémarrer son programme.

Je pourrais aussi copier la base cible sur un fichier toujours au même endroit et portant toujours le même nom, mais ce n'est pas élégant du tout, et surtout pas très sécurisé (risque d'avoir deux fichiers avec des contenus différents), sans compter le temps et la place perdus.

En outre, étant donné qu'il est serverless, je ne crois pas qu'il puisse intégrer des fonctionnalités intérrescentes qui ont fait le succes de SQL Serveur et Oracle.

A ce stade de la conversation, je pense avoir bien vu les avantages et inconvénients de travailler ou non avec un serveur.
L'intérêt pour cette petite application, c'est justement que ce soit serverless, c'est ce que je cherchais.

Il est clair (pour moi) qu'on ne peut pas à la fois vouloir se passer d'un serveur tout en bénéficiant de ses avantages

Dans le cas du facturier, le serveur ne se justifie pas. Par contre, dans le cas de mon application domotique, bien, déjà parce que je pourrais utiliser des programmes différents accédant à la même base, et ce simultanément.

Par contre, rien qu'après le peu de temps d'utilisation, je suis séduit par entities, parce que là, on se détache vraiment de la structure du fichier et de la bdd. C'est assez ahurissant.

Quand au procédure stockée, tu ne va pas comparer l'intérêt d'une procedure stockée à un code client même écrit en C#

Pour ma part, il me semble comprendre que si c'est bien pratique pour une base partagée par plusieurs programmes, par contre pour un accès par programme unique, ça perd nettement de son intérêt (sauf un gain de vitesse, mais dont je n'ai pas l'ordre de grandeur). Bref, pour l'application "facturier", ça ne m'inquiète pas. Par contre, ce sera bien utile dans mon application "domotique".

Merci
Claude

[tomlev]

Comment fait-on pour changer la base cible "au vol"?

Il faut passer une chaine de connection en paramètre du constructeur de ton entity model. Comme la chaine de connection Entity Framework a un peu une sale gueule, il faut utiliser un ConnectionStringBuilder. Un exemple tiré d'une application à moi (l'entity model s'appelle DvdEntities) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
private DvdEntities OpenDatabase(string filename)
{
    EntityConnectionStringBuilder ecsb = new EntityConnectionStringBuilder();
    ecsb.Provider = "System.Data.SQLite";
    ecsb.Metadata = MediaTek.Properties.Resources.dbMetaData;
    ecsb.ProviderConnectionString = string.Format("data source={0}", filename);
    DvdEntities db = new DvdEntities(ecsb.ConnectionString);
    return db;
}

"dbMetaData" est une chaine de caractères que j'ai mise en ressource pour alléger le code. Ca correspond à la partie "metadata" de la chaine de connexion générée par le designer, dans mon cas :

res://*/DvdModel.csdl|res://*/DvdModel.ssdl|res://*/DvdModel.msl

[ClaudeBg]

Salut

Merci beaucoup, ça fonctionne.

Maintenant, j'ai tout pour avancer

Juste une question (LOL) :

Bien que j'avais précisé à la création du modèle que je travaillais sur Sqlite, dans le fichier app.config, j'avais pour le provider :

providerName="System.Data.EntityClient"

et non

providerName="System.Data.Sqlite"

Par contre, en utilisant ta méthode pour connecter la base, ça ne fonctionne pas avec EntityClient (exception qui indique : "Soit le fournisseur de magasins spécifié est introuvable dans la configuration, soit il n'est pas valide.") , mais ça fonctionne bien avec Sqlite comme tu l'as renseigné.

Pourquoi ces deux références différentes alors que le résultat est identique?

Merci
Claude

[tomlev]

providerName="System.Data.EntityClient"

et non

providerName="System.Data.Sqlite"

Il y a une petite subtilité... en fait il y a 2 "niveaux" de provider :
- EntityClient : le provider générique d'Entity Framework, qui permet d'accéder aux données en faisant abstraction de leur mode de stockage
- Le provider sous-jacent d'accès à la BDD "réelle" (SQLite par exemple), qui est utilisé par EntityClient.

Donc la chaine de connexion générée par le code que je t'ai donné est bien destinée à être utilisée par EntityClient, mais elle indique quel est le provider sous-jacent à utiliser, ainsi que la chaine de connexion pour ce provider. Au final tu as 2 chaines de connexion "imbriquées"

[ClaudeBg]

Salut

Merci, c'est clair

Et en plus je viens de m'apercevoir que SQLite solutionne une autre de mes interrogations, puisque les types TEXT BLOB etc ne requièrent plus de définir des longueurs maximales comme VARCHAR(x).
Sans compter que le type de données n'est plus figé par la colonne, mais dépend du contenu.
Bref, c'est full dynamique : génial.

Claude