Discussion :

[ClaudeBg]

Bonjour,

Je sais qu'il y a des "pointures" linq sur ce forum. Quelqu'un peut-il donc me dire pourquoi cette méthode fonctionne :

Code :

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

1
2
3
4
5
6
7
8
9
10
            var clients =
                (from c in formMDI.Bdd.Client
                 select c).ToList();
 
            var listeClients =                                      // rechercher tous les clients pas encore utilisés
                (from c in clients
                 where !c.EstDansLeTableau(tabl1)
                 && !c.EstDansLeTableau(tabl2)
                 orderby c.NumClient
                 select c).ToList();

Mais pas celle-ci ?

Code :

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

1
2
3
4
5
6
            var listeClients2 =
                (from c in formMDI.Bdd.Client
                 where !c.EstDansLeTableau(tabl1)
                 && !c.EstDansLeTableau(tabl2)
                 orderby c.NumClient
                 select c).ToList();

dans le second cas, j'obtiens une erreur :

LINQ to Entities ne reconnaît pas la méthode « Boolean EstDansLeTableau(FactuLite.Client, System.String[]) », et cette dernière ne peut pas être traduite en expression de magasin.

Y a-t-il une solution pour éviter de créer une liste avec tous les éléments de la table avant de faire la recherche?

Pour information, voici la méthode "EstDansLeTableau", qui est toute bête :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
        public static bool EstDansLeTableau(this Client client, string[] tableau)
        {
            bool result = false;                        // valeur de retour
            if (tableau != null)
            {
                long NumTableau;                            // un numéro du tableau
                long numClient = client.NumClient;          // récupérer numéro du client
 
                foreach (var item in tableau)
                {
                    long.TryParse(item, out NumTableau);    // tenter la conversion de l'élément en long
                    if (numClient == NumTableau)            // si ce numéro est celui du client
                    {
                        result = true;                      // on a trouvé
                        break;                              // et fin de la recherche
                    }
                }
            }
            return result;
        }

Merci d'avance

Claude

[The_badger_man]

Code :

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

formMDI.Bdd.Client

est de quelle nature ?

Si c'est une entité Linq (mappée à une table) alors je pense que la réponse est la suivante:

Dans le premier cas tu fais une requête qui va être traduite en SQL par Linq to Entities. Puis tu fais un ToList qui va executer cette requête et ramener des objets.
Puis tu utilises EstDansLeTableau sur le résultat de la requête précédente, et là tu travailles sur des objets en mémoire: Linq to Object.


Dans le deuxième cas tu essayes de tout faire d'un coup. Linq to Entities essaye donc de traduire la requête en SQL. Et il plante parcequ'il ne sait pas traduire ta fonction EstDansLeTableau en SQL.

[tomlev]

- 1ere méthode : tu effectues la 1ere requête sur la base de données et tu transformes le résultat en List<Client>. La 2e requête Linq ne travaille donc plus sur un IQueryable<Client> mais sur un IEnumerable<Client>, donc la requête n'est pas transformée en SQL pour être exécutée sur la base, et l'appel à EstDansLeTableau se passe bien

- 2e méthode : tu travailles directement sur un IQueryable, sans conversion intermédiaire en IEnumerable, donc Linq essaie de transformer ta requête en SQL, mais comme la fonction EstDansLeTableau n'existe pas en SQL, ça plante...

[The_badger_man]

A part tes mots savants, c'est ce que j'ai dit

[tomlev]

A part tes mots savants, c'est ce que j'ai dit

en fait j'avais pas vu ton message quand j'ai posté...

[ClaudeBg]

Bonjour,

Merci, les deux explications sont limpides.

Si j'ai bien compris les implications :

1) Il m'est impossible d'intégrer ce genre de fonction dans une requête linq portant sur une table sqLite

2) La seule façon de procéder, si je veux éviter de rapatrier l'intégralité de la table en RAM serait donc de parcourir la table et de faire le tri dans un foreach, au lieu d'utiliser ToList. Si j'ai tout saisi, c'est justement ce que fait une requête suivie d'un ToList : une sélection au moment du parcours des éléments de la table :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
 
var query =
    from c in formMDI.Bdd.Client.Include("Adresse")
    orderby c.NumClient
    select c;
 
var listeClients = new List<Client>();          // créer une liste de clients
foreach (var client in query)                   // parcourir la table
    if (!client.EstDansLeTableau(tabl1))        // si le client n'est utilisé dans aucune des zones texte in et out
        if (!client.EstDansLeTableau(tabl2))
            listeClients.Add(client);           // l'ajouter dans la liste des clients à afficher

C'est bien ça, où il y a une méthode plus simple?

J'allais dire que ce n'était pas dérangeant pour sqLite qui travaille en local, mais que ramener tous les éléments à partir d'un serveur était lourd, quand je me suis rappelé que sqLite ne permet pas de stocker des procédures, mais sql serveur si. Serait-ce la raison de cette différence?

Merci
Claude

--------------

[tomlev]

Ben fait s'il y a des critères qui te permettent de pré-filtrer les données directement en SQL, tu peux les utiliser, faire le ToList sur le résultat, et ensuite filtrer selon ta fonction EstDansLeTableau.

Par contre, j'ai une info qui devrait te plaire

Avec SQLite, tu peux définir des fonctions en C# (ou en C, ou n'importe quel langage à partir duquel tu utilises SQLite) et les "mapper" avec un nom de fonction utilisable en SQL. J'avais testé ça il y a quelque temps, j'essaierai de te retrouver le code.

Par contre je suis pas sûr que le provider EF de SQLite soit capable de réaliser que tu as mappé la méthode C# avec une fonction SQL... en fait, en y réfléchissant un peu ça parait même peu probable