Discussion :

[talere]

Bonjour,

J'ai un soucis avec ADODB connecté à un seveur SQL-Server et plus précisément sur la combinaison tri/filtre.

Pris chacun de son coté, il n'y a pas de problème, mais lorsque j'applique un filtre, puis un tri, le nombre d'enregistrement n'est plus le même !

-> Admettons que mon jeu original contienne 300 enregistrements, quelque soit la clé de tri, croissant ou décroissant, j'ai toujours 300 enregistrements.
-> Si j'applique un filtre (propriété .Filter), mon jeu tombe à 30 enregistrements, ce qui est conforme à mon filtre
-> Si je change le tri (propriété .Sort), sur le jeu filtré, je me retrouve à avoir les 6 premiers dans l'ordre croissant, et les 9 derniers dans l'ordre décroissant!

J'ai beau cherché, je ne vois pas d'ou ça vient ... Quelqu'un peut-il m'aider ?

Mon recordset ADODB est connecté via la connexion d'un projet ADP d'Access, le curseur est coté client, de type Keyset, enfin, il est en lecture seul (je ne fais que de l'affichage ... pas de mise à jour)

Merci,

TALERE

[SQLpro]

Sans la description DDL de la table, la requête en jeu et un jeu de données... !

ma boule de cristal est devenue aveugle....

A +

[StringBuilder]

Les pilotes ADODB sont souvent buggés, et il est très courant de tomber sur des bugs ou même des fonctionnalités absentes (chaque éditeur de SGBD écrivant ses pilotes dans son coin).

En il vaut mieux se limiter strictement à :
- interrogation en langage SQL
- récupération du résutlat sans post-traitement

Si vous voulez faire des tris et filtres :
- ajouter ORDER BY et WHERE dans vos requêtes SQL
- effectués ces traitements vous-même sur le jeu de résultat, en émplémentant vos propres méthodes de tri et de filtre.

[talere]

Bonjour,

Merci pour vos réponses ... Mes investigations m'ont mené aux conclusions suivantes : L'erreur se produit à l'application d'un filtre, lorsque la clé de tri a été modifié depuis l'ouverture du Recorset ou depuis la dernière application d'un filtre.

Finalement, j'ai fini par trouver une solution :

• Je mémorise la clé de tri dans une variable de type string
• J'annule la clé
• J'applique mon filtre
• Enfin j'applique la clé de tri que j'ai mémorisé au préalable

Code :

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

1
2
3
4
5
6
7
8
9
 
Private Sub ApplyFilter(MyFilter As String)
Dim MemoSort As String
With RS_CA
    MemoSort = .Sort: .Sort = ""
    .Filter = MyFilter
    .Sort = MemoSort
End With
End Sub

La modification de la clé de tri, à posteriori, ne semble plus de problème, le bug vient bien à l’application du filtre ...

J'espère que cela pourra aider d'autre personnes

TALERE

[StringBuilder]

Et sinon, pourquoi ne pas effectuer filtre + tri dans la requête SQL directement ?

(je persiste mais bon)

[talere]

Pour la simple et bonne raison que je souhaite pas recharger le jeu d'enregistrement (temps d’exécution un peu long !). De plus étant dans un environnement multi-utilisateurs, je n'ai pas envie que le jeu change car l'utilisateur applique un tri sur une colonne précise.
-> J'ai un bouton "Recharger" qui me permet de faire cette manipulation, et l'utilisateur sait que, dans ce cas, le nombre et le contenu des enregistrements peut changer.

Toujours est-il que finalement, le problème n'est pas résolu, j'ai un nouveau bug qui est apparu, mais il semble légèrement différent.

Prenons l'exemple d'une liste de valeur {5,2,3,9,6,1,7,4,8} (les chiffres de 1 à 9, dans le désordre) et appliquons un filtre sur les valeurs supérieurs à 3. Je dois obtenir la liste {5,9,6,7,4,8} -> Si je filtre par ordre croissant, je devrais la liste {4,5,6,7,8,9} et {9,8,7,6,5,4} par ordre décroissant.
Voici les effets constatés :

• Mon premier bug (filtre sur un recordset trié) me donnait {4,5,6} en ordre croissant, et {9,8,7,6} en ordre décroissant. Mon exemple ne tient compte que d'une colonne, mais suivant la colonne trié, les effets étaient complètement différents.
• Mon nouveau bug (tri sur un recordset filtré), lui, garde le même jeu, mais il est incomplet : {4,5,6} en ordre croissant et {6,5,4} en ordre décroissant. De plus, quelque soit la colonne de tri, le jeu ne semble pas changer.

Je ne sais pas si c'est lié, mais mais mon recordset filtré et trié contient exactement 200 enregistrements (pour 464 à l'origine) .. je me demande s'il n'y a pas un paramètre initialisé à 200 quelques part ... je cherche ...

Je vous tiendrais au courant dès que j'aurais trouvé la solution ...

TALERE

[talere]

Finalement, je désactive systématiquement le filtre ... bizarrement, ça fonctionne si le tri est effectué dans un 2ème temps par l'utilisateur ...

[SQLpro]

Ceci est parfaitement normal. En effet entre une base de données qui gère des collations et accepte les NULL et fonctionne de manière ensembliste et un code client qui ne sait ni gérer l'un ni gérer l'autre et fonctionne de manière itérative, il est impossible de reproduire le comportement d'une requête côté client (défaut d'impédance)

Soit vous abandonnez cette idée saugrenue de singer le SQL par des itérations coté client. Soit vous vous passez d'une base de données relationnelle et par exemple vous revenez au bon vieux temps des fichiers et du CoBOL....

A +

[iberserk]

De plus étant dans un environnement multi-utilisateurs, je n'ai pas envie que le jeu change car l'utilisateur applique un tri sur une colonne précise.

N'importe quoi! les requêtes sont indépendante d'un utilisateur à un autres.

Commencez par vous former à l'accès aux données/base de données!

Vous parlez de performances mais elles seront bien meilleur en triant et filtrant au préalable qu'en le faisant en mémoire!

Il est simple d'implémenter une pagination côté sql server par exemple.