j'ai un gridview rattaché à un sqldatasource, jusque là pas de problème
maintenant j'aimerais pouvoir filtrer ce sqldatasource
déjà là j'ai une question, est-ce qu'il vaut mieux modifier
dynamiquement la requête sql ou est-ce que la propriété
FilterExpression est suffisament performante pour s'éviter cette
gymnastique ?
ensuite, je voudrais faire un formulaire de filtre à base de
drowdownbox contenant les différentes valeurs connues du champ qu'ils
permettent de filtrer
là est donc la deuxième question, comme les données principales
viennent d'un sqldatasource, est-ce qu'il est possible d'utiliser ce
même sqldatasource pour populer les dropdownbox ? si oui, comment gerer
le "distinct" et le cas "ne pas activer le filtre de ce dropdownbox" ?
et sinon, plus généralement, est-ce qu'il existe un composant magique
de filtrage qu'on associerait à un gridview (par exemple, ou
directement au datasource) et qui serait capable d'afficher une serie
de dropdownbox/textbox (en fonction d'un paramétrage façon collection)
avec auto-populate de ces composants ?
--
Faust
"Une âme en peine peut en cacher une autre"
"Christophe Lephay" a écrit dans le message de groupe de discussion :
"Faust" a écrit dans le message de groupe de discussion :
Tu peux avoir un problème de performance si tu appliques le filtre dans FilterExpression, mais dans l'exemple que j'ai donné, c'est la requête sql elle-même qui est modifiée par les mécanismes de binding d'asp, ce qui fait que le filtre est appliqué par le serveur sql.
justement, le serveur que j'utilise (FB) n'aime pas trop ce genre de jonglage avec les paramètres
Les expressions @Filter du code que j'avais donné en exemple ne sont pas transmises telles quelles au serveur. Asp leur substitue leur valeur réelle.
Il ne s'agissait pas de transmettre des paramètres à une procédure stockée.
Correction : il n'y a pas nécessairement substitution des paramètres par asp.
Il n'y a pas de substitution avec sql server, qui crée à la volée une requête paramétrée.
Pour les autres types de serveurs sql, j'imagine que cela dépend de l'adapter utilisé, et de la capacité du serveur sql sous-jacent à gérer ou non les requêtes paramétrées.
La doc du serveur sql répondra à cette question, en indiquant le cas échéant les contraintes à appliquer sur les noms des paramètres : préfixe @ pour sql server, ? pour mysql (de mémoire)...
"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le message
de groupe de discussion : uvulvZ9TJHA.5408@TK2MSFTNGP04.phx.gbl...
"Faust" <miss.me@no.where.invalid> a écrit dans le message de groupe de
discussion : mn.d3a27d8be72f99fd.16328@chez.moi.invalid...
Tu peux avoir un problème de performance si tu appliques le filtre dans
FilterExpression, mais dans l'exemple que j'ai donné, c'est la requête
sql elle-même qui est modifiée par les mécanismes de binding d'asp, ce
qui fait que le filtre est appliqué par le serveur sql.
justement, le serveur que j'utilise (FB) n'aime pas trop ce genre de
jonglage avec les paramètres
Les expressions @Filter du code que j'avais donné en exemple ne sont pas
transmises telles quelles au serveur. Asp leur substitue leur valeur
réelle.
Il ne s'agissait pas de transmettre des paramètres à une procédure
stockée.
Correction : il n'y a pas nécessairement substitution des paramètres par
asp.
Il n'y a pas de substitution avec sql server, qui crée à la volée une
requête paramétrée.
Pour les autres types de serveurs sql, j'imagine que cela dépend de
l'adapter utilisé, et de la capacité du serveur sql sous-jacent à gérer ou
non les requêtes paramétrées.
La doc du serveur sql répondra à cette question, en indiquant le cas échéant
les contraintes à appliquer sur les noms des paramètres : préfixe @ pour sql
server, ? pour mysql (de mémoire)...
"Christophe Lephay" a écrit dans le message de groupe de discussion :
"Faust" a écrit dans le message de groupe de discussion :
Tu peux avoir un problème de performance si tu appliques le filtre dans FilterExpression, mais dans l'exemple que j'ai donné, c'est la requête sql elle-même qui est modifiée par les mécanismes de binding d'asp, ce qui fait que le filtre est appliqué par le serveur sql.
justement, le serveur que j'utilise (FB) n'aime pas trop ce genre de jonglage avec les paramètres
Les expressions @Filter du code que j'avais donné en exemple ne sont pas transmises telles quelles au serveur. Asp leur substitue leur valeur réelle.
Il ne s'agissait pas de transmettre des paramètres à une procédure stockée.
Correction : il n'y a pas nécessairement substitution des paramètres par asp.
Il n'y a pas de substitution avec sql server, qui crée à la volée une requête paramétrée.
Pour les autres types de serveurs sql, j'imagine que cela dépend de l'adapter utilisé, et de la capacité du serveur sql sous-jacent à gérer ou non les requêtes paramétrées.
La doc du serveur sql répondra à cette question, en indiquant le cas échéant les contraintes à appliquer sur les noms des paramètres : préfixe @ pour sql server, ? pour mysql (de mémoire)...
Delf
Christophe Lephay a émis l'idée suivante :
j'ai un gridview rattaché à un sqldatasource, jusque là pas de problème
maintenant j'aimerais pouvoir filtrer ce sqldatasource
déjà là j'ai une question, est-ce qu'il vaut mieux modifier dynamiquement la requête sql ou est-ce que la propriété FilterExpression est suffisament performante pour s'éviter cette gymnastique ?
ensuite, je voudrais faire un formulaire de filtre à base de drowdownbox contenant les différentes valeurs connues du champ qu'ils permettent de filtrer
là est donc la deuxième question, comme les données principales viennent d'un sqldatasource, est-ce qu'il est possible d'utiliser ce même sqldatasource pour populer les dropdownbox ? si oui, comment gerer le "distinct" et le cas "ne pas activer le filtre de ce dropdownbox" ?
Je réponds ici car je n'ai pas le post d'origine.
Je ne connais pas SqlDataSource mais tu as ObjectDataSource qui te permet de filtrer les données en entrée en utilisant les paramètres de filtrage d'une clause WHERE en SQL. Tu peux même utiliser une DataView si nécessaire pour le SORT, etc.
Utiliser l'attribut DataSourceID sur le GridView et lui passer l'ID de l'ObjectDataSource.
On utilise ça dans le framework à mon taff, j'aime pas :|
-- Delf
Christophe Lephay a émis l'idée suivante :
j'ai un gridview rattaché à un sqldatasource, jusque là pas de problème
maintenant j'aimerais pouvoir filtrer ce sqldatasource
déjà là j'ai une question, est-ce qu'il vaut mieux modifier dynamiquement
la requête sql ou est-ce que la propriété FilterExpression est suffisament
performante pour s'éviter cette gymnastique ?
ensuite, je voudrais faire un formulaire de filtre à base de drowdownbox
contenant les différentes valeurs connues du champ qu'ils permettent de
filtrer
là est donc la deuxième question, comme les données principales viennent
d'un sqldatasource, est-ce qu'il est possible d'utiliser ce même
sqldatasource pour populer les dropdownbox ? si oui, comment gerer le
"distinct" et le cas "ne pas activer le filtre de ce dropdownbox" ?
Je réponds ici car je n'ai pas le post d'origine.
Je ne connais pas SqlDataSource mais tu as ObjectDataSource qui te
permet de filtrer les données en entrée en utilisant les paramètres de
filtrage d'une clause WHERE en SQL. Tu peux même utiliser une DataView
si nécessaire pour le SORT, etc.
Utiliser l'attribut DataSourceID sur le GridView et lui passer l'ID de
l'ObjectDataSource.
On utilise ça dans le framework à mon taff, j'aime pas :|
j'ai un gridview rattaché à un sqldatasource, jusque là pas de problème
maintenant j'aimerais pouvoir filtrer ce sqldatasource
déjà là j'ai une question, est-ce qu'il vaut mieux modifier dynamiquement la requête sql ou est-ce que la propriété FilterExpression est suffisament performante pour s'éviter cette gymnastique ?
ensuite, je voudrais faire un formulaire de filtre à base de drowdownbox contenant les différentes valeurs connues du champ qu'ils permettent de filtrer
là est donc la deuxième question, comme les données principales viennent d'un sqldatasource, est-ce qu'il est possible d'utiliser ce même sqldatasource pour populer les dropdownbox ? si oui, comment gerer le "distinct" et le cas "ne pas activer le filtre de ce dropdownbox" ?
Je réponds ici car je n'ai pas le post d'origine.
Je ne connais pas SqlDataSource mais tu as ObjectDataSource qui te permet de filtrer les données en entrée en utilisant les paramètres de filtrage d'une clause WHERE en SQL. Tu peux même utiliser une DataView si nécessaire pour le SORT, etc.
Utiliser l'attribut DataSourceID sur le GridView et lui passer l'ID de l'ObjectDataSource.
On utilise ça dans le framework à mon taff, j'aime pas :|
-- Delf
Faust
tu veux dire que je pourrais utiliser un sqldatasource comme "source" d'un objectdatasource ?
ça me plait bien cette idée !
tu fais ça comment ?
/_Delf_ a exprimé avec précision/ :
Christophe Lephay a émis l'idée suivante :
j'ai un gridview rattaché à un sqldatasource, jusque là pas de problème
maintenant j'aimerais pouvoir filtrer ce sqldatasource
déjà là j'ai une question, est-ce qu'il vaut mieux modifier dynamiquement la requête sql ou est-ce que la propriété FilterExpression est suffisament performante pour s'éviter cette gymnastique ?
ensuite, je voudrais faire un formulaire de filtre à base de drowdownbox contenant les différentes valeurs connues du champ qu'ils permettent de filtrer
là est donc la deuxième question, comme les données principales viennent d'un sqldatasource, est-ce qu'il est possible d'utiliser ce même sqldatasource pour populer les dropdownbox ? si oui, comment gerer le "distinct" et le cas "ne pas activer le filtre de ce dropdownbox" ?
Je réponds ici car je n'ai pas le post d'origine.
Je ne connais pas SqlDataSource mais tu as ObjectDataSource qui te permet de filtrer les données en entrée en utilisant les paramètres de filtrage d'une clause WHERE en SQL. Tu peux même utiliser une DataView si nécessaire pour le SORT, etc.
Utiliser l'attribut DataSourceID sur le GridView et lui passer l'ID de l'ObjectDataSource.
On utilise ça dans le framework à mon taff, j'aime pas :|
-- */Teträm/* http://www.tetram.org
"Mange d'abord, defeque ensuite: tu réfléchiras plus tard" - Proverbe Troll
tu veux dire que je pourrais utiliser un sqldatasource comme "source"
d'un objectdatasource ?
ça me plait bien cette idée !
tu fais ça comment ?
/_Delf_ a exprimé avec précision/ :
Christophe Lephay a émis l'idée suivante :
j'ai un gridview rattaché à un sqldatasource, jusque là pas de problème
maintenant j'aimerais pouvoir filtrer ce sqldatasource
déjà là j'ai une question, est-ce qu'il vaut mieux modifier dynamiquement
la requête sql ou est-ce que la propriété FilterExpression est suffisament
performante pour s'éviter cette gymnastique ?
ensuite, je voudrais faire un formulaire de filtre à base de drowdownbox
contenant les différentes valeurs connues du champ qu'ils permettent de
filtrer
là est donc la deuxième question, comme les données principales viennent
d'un sqldatasource, est-ce qu'il est possible d'utiliser ce même
sqldatasource pour populer les dropdownbox ? si oui, comment gerer le
"distinct" et le cas "ne pas activer le filtre de ce dropdownbox" ?
Je réponds ici car je n'ai pas le post d'origine.
Je ne connais pas SqlDataSource mais tu as ObjectDataSource qui te permet de
filtrer les données en entrée en utilisant les paramètres de filtrage d'une
clause WHERE en SQL. Tu peux même utiliser une DataView si nécessaire pour le
SORT, etc.
Utiliser l'attribut DataSourceID sur le GridView et lui passer l'ID de
l'ObjectDataSource.
On utilise ça dans le framework à mon taff, j'aime pas :|
--
*/Teträm/*
http://www.tetram.org
"Mange d'abord, defeque ensuite: tu réfléchiras plus tard" - Proverbe
Troll
tu veux dire que je pourrais utiliser un sqldatasource comme "source" d'un objectdatasource ?
ça me plait bien cette idée !
tu fais ça comment ?
/_Delf_ a exprimé avec précision/ :
Christophe Lephay a émis l'idée suivante :
j'ai un gridview rattaché à un sqldatasource, jusque là pas de problème
maintenant j'aimerais pouvoir filtrer ce sqldatasource
déjà là j'ai une question, est-ce qu'il vaut mieux modifier dynamiquement la requête sql ou est-ce que la propriété FilterExpression est suffisament performante pour s'éviter cette gymnastique ?
ensuite, je voudrais faire un formulaire de filtre à base de drowdownbox contenant les différentes valeurs connues du champ qu'ils permettent de filtrer
là est donc la deuxième question, comme les données principales viennent d'un sqldatasource, est-ce qu'il est possible d'utiliser ce même sqldatasource pour populer les dropdownbox ? si oui, comment gerer le "distinct" et le cas "ne pas activer le filtre de ce dropdownbox" ?
Je réponds ici car je n'ai pas le post d'origine.
Je ne connais pas SqlDataSource mais tu as ObjectDataSource qui te permet de filtrer les données en entrée en utilisant les paramètres de filtrage d'une clause WHERE en SQL. Tu peux même utiliser une DataView si nécessaire pour le SORT, etc.
Utiliser l'attribut DataSourceID sur le GridView et lui passer l'ID de l'ObjectDataSource.
On utilise ça dans le framework à mon taff, j'aime pas :|
-- */Teträm/* http://www.tetram.org
"Mange d'abord, defeque ensuite: tu réfléchiras plus tard" - Proverbe Troll
Delf
Faust a formulé la demande :
tu veux dire que je pourrais utiliser un sqldatasource comme "source" d'un objectdatasource ?
ça me plait bien cette idée !
tu fais ça comment ?
Je te récupère un exemple demain au taff, ici je n'ai même pas VS... Je le posterai demain soir voire samedi.
-- Delf
Faust a formulé la demande :
tu veux dire que je pourrais utiliser un sqldatasource comme "source" d'un
objectdatasource ?
ça me plait bien cette idée !
tu fais ça comment ?
Je te récupère un exemple demain au taff, ici je n'ai même pas VS...
Je le posterai demain soir voire samedi.
tu veux dire que je pourrais utiliser un sqldatasource comme "source" d'un objectdatasource ?
ça me plait bien cette idée !
tu fais ça comment ?
Je te récupère un exemple demain au taff, ici je n'ai même pas VS... Je le posterai demain soir voire samedi.
-- */Teträm/* http://www.tetram.org
<Jables> Personnelement, c'est pas Dieu qui me dérange, c'est son putain de fan club.. http://www.bashfr.org/?2544
Christophe Lephay
"Delf" a écrit dans le message de groupe de discussion : 492f129a$0$7768$
Christophe Lephay a émis l'idée suivante :
j'ai un gridview rattaché à un sqldatasource, jusque là pas de problème
maintenant j'aimerais pouvoir filtrer ce sqldatasource
déjà là j'ai une question, est-ce qu'il vaut mieux modifier dynamiquement la requête sql ou est-ce que la propriété FilterExpression est suffisament performante pour s'éviter cette gymnastique ?
ensuite, je voudrais faire un formulaire de filtre à base de drowdownbox contenant les différentes valeurs connues du champ qu'ils permettent de filtrer
là est donc la deuxième question, comme les données principales viennent d'un sqldatasource, est-ce qu'il est possible d'utiliser ce même sqldatasource pour populer les dropdownbox ? si oui, comment gerer le "distinct" et le cas "ne pas activer le filtre de ce dropdownbox" ?
Je réponds ici car je n'ai pas le post d'origine.
Je ne connais pas SqlDataSource mais tu as ObjectDataSource qui te permet de filtrer les données en entrée en utilisant les paramètres de filtrage d'une clause WHERE en SQL. Tu peux même utiliser une DataView si nécessaire pour le SORT, etc.
Ce mécanisme de filtrage fait partie des datatables, et est donc automatiquement disponible pour les sqldatasources comme pour les objectdatasources (pour peu que ces derniers renvoient des datatables, ce qui n'est pas forcément la meilleure option).
En passant par un sqldatasource, il est possible de filtrer directement par le biais d'une requête paramétrée, auquel cas le filtre sera effectué par le serveur sql. C'est également possible avec un objectdatasource, la seule différence étant qu'il y a juste un niveau d'indirection en plus (c'est la méthode select de l'objectdatasource qui appelle la requête paramtrée, soit directement, soit indirectement en passant par une autre classe métier).
Utiliser l'attribut DataSourceID sur le GridView et lui passer l'ID de l'ObjectDataSource.
On utilise ça dans le framework à mon taff, j'aime pas :|
C'est pourtant si pratique à utiliser...
Qu'est-ce que tu n'aimes pas dans cette approche ?
"Delf" <abuse@orange.fr> a écrit dans le message de groupe de discussion :
492f129a$0$7768$426a34cc@news.free.fr...
Christophe Lephay a émis l'idée suivante :
j'ai un gridview rattaché à un sqldatasource, jusque là pas de problème
maintenant j'aimerais pouvoir filtrer ce sqldatasource
déjà là j'ai une question, est-ce qu'il vaut mieux modifier
dynamiquement la requête sql ou est-ce que la propriété FilterExpression
est suffisament performante pour s'éviter cette gymnastique ?
ensuite, je voudrais faire un formulaire de filtre à base de drowdownbox
contenant les différentes valeurs connues du champ qu'ils permettent de
filtrer
là est donc la deuxième question, comme les données principales viennent
d'un sqldatasource, est-ce qu'il est possible d'utiliser ce même
sqldatasource pour populer les dropdownbox ? si oui, comment gerer le
"distinct" et le cas "ne pas activer le filtre de ce dropdownbox" ?
Je réponds ici car je n'ai pas le post d'origine.
Je ne connais pas SqlDataSource mais tu as ObjectDataSource qui te permet
de filtrer les données en entrée en utilisant les paramètres de filtrage
d'une clause WHERE en SQL. Tu peux même utiliser une DataView si
nécessaire pour le SORT, etc.
Ce mécanisme de filtrage fait partie des datatables, et est donc
automatiquement disponible pour les sqldatasources comme pour les
objectdatasources (pour peu que ces derniers renvoient des datatables, ce
qui n'est pas forcément la meilleure option).
En passant par un sqldatasource, il est possible de filtrer directement par
le biais d'une requête paramétrée, auquel cas le filtre sera effectué par le
serveur sql. C'est également possible avec un objectdatasource, la seule
différence étant qu'il y a juste un niveau d'indirection en plus (c'est la
méthode select de l'objectdatasource qui appelle la requête paramtrée, soit
directement, soit indirectement en passant par une autre classe métier).
Utiliser l'attribut DataSourceID sur le GridView et lui passer l'ID de
l'ObjectDataSource.
On utilise ça dans le framework à mon taff, j'aime pas :|
C'est pourtant si pratique à utiliser...
Qu'est-ce que tu n'aimes pas dans cette approche ?
"Delf" a écrit dans le message de groupe de discussion : 492f129a$0$7768$
Christophe Lephay a émis l'idée suivante :
j'ai un gridview rattaché à un sqldatasource, jusque là pas de problème
maintenant j'aimerais pouvoir filtrer ce sqldatasource
déjà là j'ai une question, est-ce qu'il vaut mieux modifier dynamiquement la requête sql ou est-ce que la propriété FilterExpression est suffisament performante pour s'éviter cette gymnastique ?
ensuite, je voudrais faire un formulaire de filtre à base de drowdownbox contenant les différentes valeurs connues du champ qu'ils permettent de filtrer
là est donc la deuxième question, comme les données principales viennent d'un sqldatasource, est-ce qu'il est possible d'utiliser ce même sqldatasource pour populer les dropdownbox ? si oui, comment gerer le "distinct" et le cas "ne pas activer le filtre de ce dropdownbox" ?
Je réponds ici car je n'ai pas le post d'origine.
Je ne connais pas SqlDataSource mais tu as ObjectDataSource qui te permet de filtrer les données en entrée en utilisant les paramètres de filtrage d'une clause WHERE en SQL. Tu peux même utiliser une DataView si nécessaire pour le SORT, etc.
Ce mécanisme de filtrage fait partie des datatables, et est donc automatiquement disponible pour les sqldatasources comme pour les objectdatasources (pour peu que ces derniers renvoient des datatables, ce qui n'est pas forcément la meilleure option).
En passant par un sqldatasource, il est possible de filtrer directement par le biais d'une requête paramétrée, auquel cas le filtre sera effectué par le serveur sql. C'est également possible avec un objectdatasource, la seule différence étant qu'il y a juste un niveau d'indirection en plus (c'est la méthode select de l'objectdatasource qui appelle la requête paramtrée, soit directement, soit indirectement en passant par une autre classe métier).
Utiliser l'attribut DataSourceID sur le GridView et lui passer l'ID de l'ObjectDataSource.
On utilise ça dans le framework à mon taff, j'aime pas :|
C'est pourtant si pratique à utiliser...
Qu'est-ce que tu n'aimes pas dans cette approche ?
Christophe Lephay
"Faust" a écrit dans le message de groupe de discussion :
tu veux dire que je pourrais utiliser un sqldatasource comme "source" d'un objectdatasource ?
Non. On ne peut pas binder plusieurs datasources entre eux (sauf erreur de ma part), pour la simple raison qu'un datasource renvoie un ensemble de donnée alors que le binding demande plutôt un scalaire (une valeur unique).
ça me plait bien cette idée !
tu fais ça comment ?
Tu peux avoir un premier ObjectDatasource qui te renvoie une liste d'objets de type A, ayant comme clé primaire un champ IdA. Tu connectes un formview/detailview/gridview à cet ObjectDataSource et lui affectes IdA à la propriété DataKeyNames.
Tu peux ensuite utiliser la propriété SelectedValue de ton formulaire comme paramètre pour un second ObjectDatasource.
Un SqlDataSource fonctionne exactement de la même manière à ce niveau.
C'est en général une mauvaise idée de mixer ObjectDataSources et SqlDataSource du fait de l'idée même derrière l'ObjectDataSource, qui consiste à masquer la base de donnée utilisée en passant par une couche métier intermédiaire.
"Faust" <miss.me@no.where.invalid> a écrit dans le message de groupe de
discussion : mn.dd6b7d8bfa871c78.16328@chez.moi.invalid...
tu veux dire que je pourrais utiliser un sqldatasource comme "source" d'un
objectdatasource ?
Non. On ne peut pas binder plusieurs datasources entre eux (sauf erreur de
ma part), pour la simple raison qu'un datasource renvoie un ensemble de
donnée alors que le binding demande plutôt un scalaire (une valeur unique).
ça me plait bien cette idée !
tu fais ça comment ?
Tu peux avoir un premier ObjectDatasource qui te renvoie une liste d'objets
de type A, ayant comme clé primaire un champ IdA. Tu connectes un
formview/detailview/gridview à cet ObjectDataSource et lui affectes IdA à la
propriété DataKeyNames.
Tu peux ensuite utiliser la propriété SelectedValue de ton formulaire comme
paramètre pour un second ObjectDatasource.
Un SqlDataSource fonctionne exactement de la même manière à ce niveau.
C'est en général une mauvaise idée de mixer ObjectDataSources et
SqlDataSource du fait de l'idée même derrière l'ObjectDataSource, qui
consiste à masquer la base de donnée utilisée en passant par une couche
métier intermédiaire.
"Faust" a écrit dans le message de groupe de discussion :
tu veux dire que je pourrais utiliser un sqldatasource comme "source" d'un objectdatasource ?
Non. On ne peut pas binder plusieurs datasources entre eux (sauf erreur de ma part), pour la simple raison qu'un datasource renvoie un ensemble de donnée alors que le binding demande plutôt un scalaire (une valeur unique).
ça me plait bien cette idée !
tu fais ça comment ?
Tu peux avoir un premier ObjectDatasource qui te renvoie une liste d'objets de type A, ayant comme clé primaire un champ IdA. Tu connectes un formview/detailview/gridview à cet ObjectDataSource et lui affectes IdA à la propriété DataKeyNames.
Tu peux ensuite utiliser la propriété SelectedValue de ton formulaire comme paramètre pour un second ObjectDatasource.
Un SqlDataSource fonctionne exactement de la même manière à ce niveau.
C'est en général une mauvaise idée de mixer ObjectDataSources et SqlDataSource du fait de l'idée même derrière l'ObjectDataSource, qui consiste à masquer la base de donnée utilisée en passant par une couche métier intermédiaire.
Delf
Christophe Lephay avait prétendu :
Je réponds ici car je n'ai pas le post d'origine.
Je ne connais pas SqlDataSource mais tu as ObjectDataSource qui te permet de filtrer les données en entrée en utilisant les paramètres de filtrage d'une clause WHERE en SQL. Tu peux même utiliser une DataView si nécessaire pour le SORT, etc.
Ce mécanisme de filtrage fait partie des datatables, et est donc automatiquement disponible pour les sqldatasources comme pour les objectdatasources (pour peu que ces derniers renvoient des datatables, ce qui n'est pas forcément la meilleure option).
Pas la meilleure option, pourquoi ? Tu veux parler des DataSets ?
En passant par un sqldatasource, il est possible de filtrer directement par le biais d'une requête paramétrée, auquel cas le filtre sera effectué par le serveur sql. C'est également possible avec un objectdatasource, la seule différence étant qu'il y a juste un niveau d'indirection en plus (c'est la méthode select de l'objectdatasource qui appelle la requête paramtrée, soit directement, soit indirectement en passant par une autre classe métier).
Le Select se fait sur le DataTable donc sur l'ojet lui-même et non la base. Ca permet de ne pas requêter le SGBD pour faire du filtrage.
Utiliser l'attribut DataSourceID sur le GridView et lui passer l'ID de l'ObjectDataSource.
On utilise ça dans le framework à mon taff, j'aime pas :|
C'est pourtant si pratique à utiliser...
Qu'est-ce que tu n'aimes pas dans cette approche ?
J'aime bien voir comment sont binder les listes, grilles côté codebehind.
-- Delf
Christophe Lephay avait prétendu :
Je réponds ici car je n'ai pas le post d'origine.
Je ne connais pas SqlDataSource mais tu as ObjectDataSource qui te permet
de filtrer les données en entrée en utilisant les paramètres de filtrage
d'une clause WHERE en SQL. Tu peux même utiliser une DataView si nécessaire
pour le SORT, etc.
Ce mécanisme de filtrage fait partie des datatables, et est donc
automatiquement disponible pour les sqldatasources comme pour les
objectdatasources (pour peu que ces derniers renvoient des datatables, ce qui
n'est pas forcément la meilleure option).
Pas la meilleure option, pourquoi ? Tu veux parler des DataSets ?
En passant par un sqldatasource, il est possible de filtrer directement par
le biais d'une requête paramétrée, auquel cas le filtre sera effectué par le
serveur sql. C'est également possible avec un objectdatasource, la seule
différence étant qu'il y a juste un niveau d'indirection en plus (c'est la
méthode select de l'objectdatasource qui appelle la requête paramtrée, soit
directement, soit indirectement en passant par une autre classe métier).
Le Select se fait sur le DataTable donc sur l'ojet lui-même et non la
base. Ca permet de ne pas requêter le SGBD pour faire du filtrage.
Utiliser l'attribut DataSourceID sur le GridView et lui passer l'ID de
l'ObjectDataSource.
On utilise ça dans le framework à mon taff, j'aime pas :|
C'est pourtant si pratique à utiliser...
Qu'est-ce que tu n'aimes pas dans cette approche ?
J'aime bien voir comment sont binder les listes, grilles côté
codebehind.
Je ne connais pas SqlDataSource mais tu as ObjectDataSource qui te permet de filtrer les données en entrée en utilisant les paramètres de filtrage d'une clause WHERE en SQL. Tu peux même utiliser une DataView si nécessaire pour le SORT, etc.
Ce mécanisme de filtrage fait partie des datatables, et est donc automatiquement disponible pour les sqldatasources comme pour les objectdatasources (pour peu que ces derniers renvoient des datatables, ce qui n'est pas forcément la meilleure option).
Pas la meilleure option, pourquoi ? Tu veux parler des DataSets ?
En passant par un sqldatasource, il est possible de filtrer directement par le biais d'une requête paramétrée, auquel cas le filtre sera effectué par le serveur sql. C'est également possible avec un objectdatasource, la seule différence étant qu'il y a juste un niveau d'indirection en plus (c'est la méthode select de l'objectdatasource qui appelle la requête paramtrée, soit directement, soit indirectement en passant par une autre classe métier).
Le Select se fait sur le DataTable donc sur l'ojet lui-même et non la base. Ca permet de ne pas requêter le SGBD pour faire du filtrage.
Utiliser l'attribut DataSourceID sur le GridView et lui passer l'ID de l'ObjectDataSource.
On utilise ça dans le framework à mon taff, j'aime pas :|
C'est pourtant si pratique à utiliser...
Qu'est-ce que tu n'aimes pas dans cette approche ?
J'aime bien voir comment sont binder les listes, grilles côté codebehind.
-- Delf
Christophe Lephay
"Delf" a écrit dans le message de groupe de discussion : 493062dc$0$15425$
Christophe Lephay avait prétendu :
Je réponds ici car je n'ai pas le post d'origine.
Je ne connais pas SqlDataSource mais tu as ObjectDataSource qui te permet de filtrer les données en entrée en utilisant les paramètres de filtrage d'une clause WHERE en SQL. Tu peux même utiliser une DataView si nécessaire pour le SORT, etc.
Ce mécanisme de filtrage fait partie des datatables, et est donc automatiquement disponible pour les sqldatasources comme pour les objectdatasources (pour peu que ces derniers renvoient des datatables, ce qui n'est pas forcément la meilleure option).
Pas la meilleure option, pourquoi ? Tu veux parler des DataSets ?
Je parle de faire renvoyer un DataTable par un ObjectDataSource. C'est incompatible avec la raison pour laquelle j'utilise ObjectDataSource (incompatibilité conceptuelle et non technique).
La raison principale pour laquelle j'utilise des ObjectDataSources, c'est pour bénéficier d'une sémantique totalement Objet plutôt qu'une sémantique BDD. Faire renvoyer des DataTables me fait perdre une grande partie de ce bénéfice.
En passant par un sqldatasource, il est possible de filtrer directement par le biais d'une requête paramétrée, auquel cas le filtre sera effectué par le serveur sql. C'est également possible avec un objectdatasource, la seule différence étant qu'il y a juste un niveau d'indirection en plus (c'est la méthode select de l'objectdatasource qui appelle la requête paramtrée, soit directement, soit indirectement en passant par une autre classe métier).
Le Select se fait sur le DataTable donc sur l'ojet lui-même et non la base. Ca permet de ne pas requêter le SGBD pour faire du filtrage.
Avec un SqlDataSource, tu peux faire les deux. Soit avec FilterExpression, soit en passant par une requête paramétrée, auquel cas la sélection sera faite par le serveur sql.
Avec un ObjectDataSource, tu ne peux utiliser FilterExpression qu'à la condition que ton ODS te renvoie un DataTable. En revanche, tu peux dans tous les cas passer par une requête paramétrée (filtrée/triée par le serveur, donc).
Utiliser l'attribut DataSourceID sur le GridView et lui passer l'ID de l'ObjectDataSource.
On utilise ça dans le framework à mon taff, j'aime pas :|
C'est pourtant si pratique à utiliser...
Qu'est-ce que tu n'aimes pas dans cette approche ?
J'aime bien voir comment sont binder les listes, grilles côté codebehind.
S'il s'agit de le voir, c'est visible dans le code de la page...
"Delf" <abuse@orange.fr> a écrit dans le message de groupe de discussion :
493062dc$0$15425$426a34cc@news.free.fr...
Christophe Lephay avait prétendu :
Je réponds ici car je n'ai pas le post d'origine.
Je ne connais pas SqlDataSource mais tu as ObjectDataSource qui te
permet de filtrer les données en entrée en utilisant les paramètres de
filtrage d'une clause WHERE en SQL. Tu peux même utiliser une DataView
si nécessaire pour le SORT, etc.
Ce mécanisme de filtrage fait partie des datatables, et est donc
automatiquement disponible pour les sqldatasources comme pour les
objectdatasources (pour peu que ces derniers renvoient des datatables, ce
qui n'est pas forcément la meilleure option).
Pas la meilleure option, pourquoi ? Tu veux parler des DataSets ?
Je parle de faire renvoyer un DataTable par un ObjectDataSource. C'est
incompatible avec la raison pour laquelle j'utilise ObjectDataSource
(incompatibilité conceptuelle et non technique).
La raison principale pour laquelle j'utilise des ObjectDataSources, c'est
pour bénéficier d'une sémantique totalement Objet plutôt qu'une sémantique
BDD. Faire renvoyer des DataTables me fait perdre une grande partie de ce
bénéfice.
En passant par un sqldatasource, il est possible de filtrer directement
par le biais d'une requête paramétrée, auquel cas le filtre sera effectué
par le serveur sql. C'est également possible avec un objectdatasource, la
seule différence étant qu'il y a juste un niveau d'indirection en plus
(c'est la méthode select de l'objectdatasource qui appelle la requête
paramtrée, soit directement, soit indirectement en passant par une autre
classe métier).
Le Select se fait sur le DataTable donc sur l'ojet lui-même et non la
base. Ca permet de ne pas requêter le SGBD pour faire du filtrage.
Avec un SqlDataSource, tu peux faire les deux. Soit avec FilterExpression,
soit en passant par une requête paramétrée, auquel cas la sélection sera
faite par le serveur sql.
Avec un ObjectDataSource, tu ne peux utiliser FilterExpression qu'à la
condition que ton ODS te renvoie un DataTable. En revanche, tu peux dans
tous les cas passer par une requête paramétrée (filtrée/triée par le
serveur, donc).
Utiliser l'attribut DataSourceID sur le GridView et lui passer l'ID de
l'ObjectDataSource.
On utilise ça dans le framework à mon taff, j'aime pas :|
C'est pourtant si pratique à utiliser...
Qu'est-ce que tu n'aimes pas dans cette approche ?
J'aime bien voir comment sont binder les listes, grilles côté codebehind.
S'il s'agit de le voir, c'est visible dans le code de la page...
"Delf" a écrit dans le message de groupe de discussion : 493062dc$0$15425$
Christophe Lephay avait prétendu :
Je réponds ici car je n'ai pas le post d'origine.
Je ne connais pas SqlDataSource mais tu as ObjectDataSource qui te permet de filtrer les données en entrée en utilisant les paramètres de filtrage d'une clause WHERE en SQL. Tu peux même utiliser une DataView si nécessaire pour le SORT, etc.
Ce mécanisme de filtrage fait partie des datatables, et est donc automatiquement disponible pour les sqldatasources comme pour les objectdatasources (pour peu que ces derniers renvoient des datatables, ce qui n'est pas forcément la meilleure option).
Pas la meilleure option, pourquoi ? Tu veux parler des DataSets ?
Je parle de faire renvoyer un DataTable par un ObjectDataSource. C'est incompatible avec la raison pour laquelle j'utilise ObjectDataSource (incompatibilité conceptuelle et non technique).
La raison principale pour laquelle j'utilise des ObjectDataSources, c'est pour bénéficier d'une sémantique totalement Objet plutôt qu'une sémantique BDD. Faire renvoyer des DataTables me fait perdre une grande partie de ce bénéfice.
En passant par un sqldatasource, il est possible de filtrer directement par le biais d'une requête paramétrée, auquel cas le filtre sera effectué par le serveur sql. C'est également possible avec un objectdatasource, la seule différence étant qu'il y a juste un niveau d'indirection en plus (c'est la méthode select de l'objectdatasource qui appelle la requête paramtrée, soit directement, soit indirectement en passant par une autre classe métier).
Le Select se fait sur le DataTable donc sur l'ojet lui-même et non la base. Ca permet de ne pas requêter le SGBD pour faire du filtrage.
Avec un SqlDataSource, tu peux faire les deux. Soit avec FilterExpression, soit en passant par une requête paramétrée, auquel cas la sélection sera faite par le serveur sql.
Avec un ObjectDataSource, tu ne peux utiliser FilterExpression qu'à la condition que ton ODS te renvoie un DataTable. En revanche, tu peux dans tous les cas passer par une requête paramétrée (filtrée/triée par le serveur, donc).
Utiliser l'attribut DataSourceID sur le GridView et lui passer l'ID de l'ObjectDataSource.
On utilise ça dans le framework à mon taff, j'aime pas :|
C'est pourtant si pratique à utiliser...
Qu'est-ce que tu n'aimes pas dans cette approche ?
J'aime bien voir comment sont binder les listes, grilles côté codebehind.
S'il s'agit de le voir, c'est visible dans le code de la page...
