distinct et distinctrow

Daniel

08/09/2003 à 19:31

distinctrow - l'enregistrement doit etre unique
distinct- les champ de l'enregistrment doit etre unique

Je sais toujours pas dans quelle situation, distinctrow s'applique et non
distinct

De toute facon je vais seulement utiliser distinct car je prévois passer de
access 97 a sql server 2000,
avec 200 tables et 600+requetes ,je vais avoir les cheveux blancs avant
d'avoir fini...

"Daniel" a écrit dans le message de
news:%23cT%

Salut
J'aimerais savoir l'utilité de distinctrow par rapport a distinct

J'aimerais savoir dans quelle situation il est mieux d'utiliser
distinctrow

au lieu de distinct

Merci

Michel Walsh

08/09/2003 à 20:18

Salut,

Utiliser DISTINCT dans le sens général d'obtenir un seul enregistrement
(tous champs confondus), un peu comme le ferait un GROUP BY appliqué sur
tous et chacun des champs sélectionnés.

Utiliser DISTINCTROW, propriétaire à Jet, si on désire qu'au plus un
enregistrement par valeur, tous champs sélectionnés confondus, par table
originalement impliqué, ce qui est généralement le cas pour une requête de
type DELETE sur une jointure, car DISTRINCTROW ne détruit pas la possibilité
de mettre à jour les enregistrements. C'est souvent pour cette dernière
raison qu'on l'utilise, d'ailleurs.

Ainsi, si une table t1 possède un champ, f1, avec trois enregistrements,
tous trois ayant la valeur "a",

t1 ' table
f1 ' champ
"a"
"a"
"a" ' valeurs

SELECT a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
retourne 9 enregistrements,

SELECT DISTINCT a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
retourne 1 enregistrement,

SELECT DISTINCTROW a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
retourne 3 enregistrements ( des 9 premiers, mais, selon ce qui est
sélectionné, on ne conserve, par valeur, qu'au plus un enregistrement par
table impliquée dans la sélection ).

Pareillement, si la table t1 possède "a", "a", "b" (au lieu de trois
enregistrements chacun avec un "a"), les nombres d'enregistrements retournés
sont de 5, 2 et 3, respectivement (avec ALL, avec DISTINCT et avec
DISTINCTROW).

En effet, si on n'utilise ni DISTINCT, ni DISTINCTROW, implicitement, on
utilise ALL

SELECT ALL a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
est équivalent à
SELECT a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1

Espérant être utile,
Vanderghast, Access MVP

"Daniel" wrote in message
news:%23cT%

Salut
J'aimerais savoir l'utilité de distinctrow par rapport a distinct

J'aimerais savoir dans quelle situation il est mieux d'utiliser
distinctrow

au lieu de distinct

Merci

Salut,

Utiliser DISTINCT dans le sens général d'obtenir un seul enregistrement
(tous champs confondus), un peu comme le ferait un GROUP BY appliqué sur
tous et chacun des champs sélectionnés.

Utiliser DISTINCTROW, propriétaire à Jet, si on désire qu'au plus un
enregistrement par valeur, tous champs sélectionnés confondus, par table
originalement impliqué, ce qui est généralement le cas pour une requête de
type DELETE sur une jointure, car DISTRINCTROW ne détruit pas la possibilité
de mettre à jour les enregistrements. C'est souvent pour cette dernière
raison qu'on l'utilise, d'ailleurs.

Ainsi, si une table t1 possède un champ, f1, avec trois enregistrements,
tous trois ayant la valeur "a",

t1 ' table
f1 ' champ
"a"
"a"
"a" ' valeurs

SELECT a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
retourne 9 enregistrements,

SELECT DISTINCT a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
retourne 1 enregistrement,

SELECT DISTINCTROW a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
retourne 3 enregistrements ( des 9 premiers, mais, selon ce qui est
sélectionné, on ne conserve, par valeur, qu'au plus un enregistrement par
table impliquée dans la sélection ).

Pareillement, si la table t1 possède "a", "a", "b" (au lieu de trois
enregistrements chacun avec un "a"), les nombres d'enregistrements retournés
sont de 5, 2 et 3, respectivement (avec ALL, avec DISTINCT et avec
DISTINCTROW).

En effet, si on n'utilise ni DISTINCT, ni DISTINCTROW, implicitement, on
utilise ALL

SELECT ALL a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
est équivalent à
SELECT a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1

Espérant être utile,
Vanderghast, Access MVP

"Daniel" <no@spam.net> wrote in message
news:%23cT%23NuidDHA.3596@TK2MSFTNGP11.phx.gbl...

Salut
J'aimerais savoir l'utilité de distinctrow par rapport a distinct

J'aimerais savoir dans quelle situation il est mieux d'utiliser
distinctrow

au lieu de distinct

Merci

Anor

08/09/2003 à 20:21

Bonjour

Daniel a confié :
| Salut
| J'aimerais savoir l'utilité de distinctrow par rapport a distinct
|
| J'aimerais savoir dans quelle situation il est mieux d'utiliser
| distinctrow au lieu de distinct
|
| Merci

Lis donc la réponse de Michel Walsh à Frédéric Brouard du 08/09/2003 à 13:41 intitulée
Re: Nouveautés sur SQL dans le site SQLpro...

Il y a au moins un passage (sinon tous) qui risquent de t'intéresser ;-)

--
à+
Arnaud
--------------------------------------------------
Conseils d'utilisation, sites recommandés :
http://users.skynet.be/mpfa/
Access Memorandum - http://memoaccess.free.fr
--------------------------------------------------

Daniel

08/09/2003 à 20:42

Merci a vous 2 , ca m'a vraiment éclairci

"Anor" a écrit dans le message de
news:%

Bonjour

Daniel a confié :
| Salut
| J'aimerais savoir l'utilité de distinctrow par rapport a distinct
|
| J'aimerais savoir dans quelle situation il est mieux d'utiliser
| distinctrow au lieu de distinct
|
| Merci

Lis donc la réponse de Michel Walsh à Frédéric Brouard du 08/09/2003 à
13:41 intitulée

Re: Nouveautés sur SQL dans le site SQLpro...

Il y a au moins un passage (sinon tous) qui risquent de t'intéresser ;-)

--
à+
Arnaud
--------------------------------------------------
Conseils d'utilisation, sites recommandés :
http://users.skynet.be/mpfa/
Access Memorandum - http://memoaccess.free.fr
--------------------------------------------------

3stone

08/09/2003 à 20:55

Salut,

Daniel

J'aimerais savoir l'utilité de distinctrow par rapport a distinct

Ouvre une requête en mode création/modification.

Clique dans la surface grise à coté de la table et demande les propriétés.
Là, tu trouvera deux lignes:

- Valeurs distinctes ( Distinct )
- Enregistrements uniques ( Distinctrow )

Si tu mets une des valeurs à "Oui", tu remarquera que l'autre prend automatiquement la valeur
"Non".
Teste les différentes possibilités et regarde à chaque fois ta requête en mode SQL

Pour ta requête, tu ne choisi qu'un seul champ dont il existe plusieurs occurences dans la
table.
Tu remarquera, que la propriété: "Valeurs distinctes = Oui" (SELECT DISTINCT) ne t'affiche
qu'une seule fois chaque valeur du champ.
Très utile par exemple, si tu crée une liste avec toutes les valeurs d'un champ,
mais, en ne le présentant qu'une seule fois chaque valeur.

J'aimerais savoir dans quelle situation il est mieux d'utiliser distinctrow
au lieu de distinct

Distinctrow n'est utile que si la requête est basée sur plusieurs tables

PS:
Pour ce genre de question l'aide est simple à obtenir...
Ecrire dans le VBA le mot incompris, placer le curseur dessus et faire F1

--
A+
Pierre (3stone) Access MVP
--------------------------------------
Une pour tous, tous pour une ;-)
http://users.skynet.be/mpfa/
--------------------------------------

Michel Walsh

08/09/2003 à 21:25

Salut,

Précisions, j'aurais du écrire

"par tableS impliquéeS DANS LE SELECT".

Dans le premier, seule la table a est impliquée, a.f1 fourni une seule
valeur, "a", donc, des 9 enregistrements initiaux, tous produisant "a", je
me limite à un seul par enregistrement initial, ce qui nous laisse 3
enregistrements.

Le second cas est plus illustratif. Le produit cartésien, produire toutes
les combinaisons possibles, fournirait:

provient des energistements numéro
a.f1 b.f1 de a de b
a a 1 1
a a 1 2
a b 1 3
a a 2 1
a a 2 2
a b 2 3
b a 3 1
b a 3 2
b b 3 3

ainsi, la quatrième ligne provient de la combinaison du second
enregistrement de a et du permier enregistrement de b (pour illustration
seulement, en fait, on utiliserait des "signets", ou "bookmarks", ou les
clés primaires).

La jointure interne nous force à ne conserver que ceux où a.f1=b.f1

a.f1 b.f1 de a de b
a a 1 1
a a 1 2
' a b 1 3 ' éliminé, a<>b
a a 2 1
a a 2 2
' a b 2 3 ' éliminé, a<>b
' b a 3 1 ' éliminé, b<>a
' b a 3 2 ' éliminé, b<>a
b b 3 3

Le SELECT ne considère que la table "a". On élimine toutes informations (et
repérages) concernant la table "b".

a.f1 de_a
a 1
a 1
a 2
a 2
b 3

Le DISCTINCTROW connaît qu'il y a deux valeurs, "a" et "b", et de ne
conserver, pour chacune d'elles, qu'un seul cas par enregistrement initial.
C'est un peu comme si on effectuait un "GROUP BY" sur a.f1, et sur le
"repérage de provenance de quel enregistrement de la table a". On se
retrouve donc avec:

a.f1 de_a
a 1
a 2
b 3

où la valeur "a" est encore "double", car elle est dans deux
enregistrements, initialement, dans la table.

La dernière manipulation est d'éradiquer toute trace des "méta données", on
élimine donc nos "signets" qui nous indiquaient la provenance de
l'enregistrement initial, et le résultat est:

a.f1
a
a
b

Évidemment, c'est un cas fabriqué, mais les points importants sont:

- il y a "à quelque part" conservation du "repérage" de la
provenance (utile pour effacer, disons), mais cela pourrait ralentir ou
restreindre les possibilités d'optimisation...
- il n'y a pas plus qu'un enregistrement par enregistrements de(s)
table(s) impliquée(s) dans le SELECT, par tuple (ensemble des champs)
constitué par la sélection (PAS par la jointure). Ceci peut être utile si on
conserve, dans le SELECT, un nombre moindre de tables que celui impliqué
dans la JOINTURE. Si ce point nécessite éclaircissement, prière de le dire
(en réponse, ici), car un exemple qui illustrerait le concept avec détails
pertinents est, à première vue, un peu volumineux: il faut au moins trois
tables jointes, pour n'en conserver que deux dans le SELECT, si on désire
quelque chose de plus "parlant" que l'exemple ci-haut.

Espérant être utile,
Vanderghast, Access MVP

"Michel Walsh" wrote in message
news:%

Salut,

Utiliser DISTINCT dans le sens général d'obtenir un seul
enregistrement

(tous champs confondus), un peu comme le ferait un GROUP BY appliqué sur
tous et chacun des champs sélectionnés.

Utiliser DISTINCTROW, propriétaire à Jet, si on désire qu'au plus un
enregistrement par valeur, tous champs sélectionnés confondus, par table
originalement impliqué, ce qui est généralement le cas pour une requête de
type DELETE sur une jointure, car DISTRINCTROW ne détruit pas la
possibilité

de mettre à jour les enregistrements. C'est souvent pour cette dernière
raison qu'on l'utilise, d'ailleurs.

Ainsi, si une table t1 possède un champ, f1, avec trois
enregistrements,

tous trois ayant la valeur "a",

t1 ' table
f1 ' champ
"a"
"a"
"a" ' valeurs

SELECT a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
retourne 9 enregistrements,

SELECT DISTINCT a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
retourne 1 enregistrement,

SELECT DISTINCTROW a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
retourne 3 enregistrements ( des 9 premiers, mais, selon ce qui est
sélectionné, on ne conserve, par valeur, qu'au plus un enregistrement par
table impliquée dans la sélection ).

Pareillement, si la table t1 possède "a", "a", "b" (au lieu de trois
enregistrements chacun avec un "a"), les nombres d'enregistrements
retournés

sont de 5, 2 et 3, respectivement (avec ALL, avec DISTINCT et avec
DISTINCTROW).

En effet, si on n'utilise ni DISTINCT, ni DISTINCTROW, implicitement, on
utilise ALL

SELECT ALL a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
est équivalent à
SELECT a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1

Espérant être utile,
Vanderghast, Access MVP

"Daniel" wrote in message
news:%23cT%
Salut
J'aimerais savoir l'utilité de distinctrow par rapport a distinct

J'aimerais savoir dans quelle situation il est mieux d'utiliser
distinctrow

au lieu de distinct

Merci

Salut,

Précisions, j'aurais du écrire

"par tableS impliquéeS DANS LE SELECT".

Dans le premier, seule la table a est impliquée, a.f1 fourni une seule
valeur, "a", donc, des 9 enregistrements initiaux, tous produisant "a", je
me limite à un seul par enregistrement initial, ce qui nous laisse 3
enregistrements.

Le second cas est plus illustratif. Le produit cartésien, produire toutes
les combinaisons possibles, fournirait:

provient des energistements numéro
a.f1 b.f1 de a de b
a a 1 1
a a 1 2
a b 1 3
a a 2 1
a a 2 2
a b 2 3
b a 3 1
b a 3 2
b b 3 3

ainsi, la quatrième ligne provient de la combinaison du second
enregistrement de a et du permier enregistrement de b (pour illustration
seulement, en fait, on utiliserait des "signets", ou "bookmarks", ou les
clés primaires).

La jointure interne nous force à ne conserver que ceux où a.f1=b.f1

a.f1 b.f1 de a de b
a a 1 1
a a 1 2
' a b 1 3 ' éliminé, a<>b
a a 2 1
a a 2 2
' a b 2 3 ' éliminé, a<>b
' b a 3 1 ' éliminé, b<>a
' b a 3 2 ' éliminé, b<>a
b b 3 3

Le SELECT ne considère que la table "a". On élimine toutes informations (et
repérages) concernant la table "b".

a.f1 de_a
a 1
a 1
a 2
a 2
b 3

Le DISCTINCTROW connaît qu'il y a deux valeurs, "a" et "b", et de ne
conserver, pour chacune d'elles, qu'un seul cas par enregistrement initial.
C'est un peu comme si on effectuait un "GROUP BY" sur a.f1, et sur le
"repérage de provenance de quel enregistrement de la table a". On se
retrouve donc avec:

a.f1 de_a
a 1
a 2
b 3

où la valeur "a" est encore "double", car elle est dans deux
enregistrements, initialement, dans la table.

La dernière manipulation est d'éradiquer toute trace des "méta données", on
élimine donc nos "signets" qui nous indiquaient la provenance de
l'enregistrement initial, et le résultat est:

a.f1
a
a
b

Évidemment, c'est un cas fabriqué, mais les points importants sont:

- il y a "à quelque part" conservation du "repérage" de la
provenance (utile pour effacer, disons), mais cela pourrait ralentir ou
restreindre les possibilités d'optimisation...
- il n'y a pas plus qu'un enregistrement par enregistrements de(s)
table(s) impliquée(s) dans le SELECT, par tuple (ensemble des champs)
constitué par la sélection (PAS par la jointure). Ceci peut être utile si on
conserve, dans le SELECT, un nombre moindre de tables que celui impliqué
dans la JOINTURE. Si ce point nécessite éclaircissement, prière de le dire
(en réponse, ici), car un exemple qui illustrerait le concept avec détails
pertinents est, à première vue, un peu volumineux: il faut au moins trois
tables jointes, pour n'en conserver que deux dans le SELECT, si on désire
quelque chose de plus "parlant" que l'exemple ci-haut.

Espérant être utile,
Vanderghast, Access MVP

"Michel Walsh" <vanderghast@msn.com> wrote in message
news:%23IgHpcjdDHA.3876@TK2MSFTNGP11.phx.gbl...

Salut,

Utiliser DISTINCT dans le sens général d'obtenir un seul
enregistrement

(tous champs confondus), un peu comme le ferait un GROUP BY appliqué sur
tous et chacun des champs sélectionnés.

Utiliser DISTINCTROW, propriétaire à Jet, si on désire qu'au plus un
enregistrement par valeur, tous champs sélectionnés confondus, par table
originalement impliqué, ce qui est généralement le cas pour une requête de
type DELETE sur une jointure, car DISTRINCTROW ne détruit pas la
possibilité

de mettre à jour les enregistrements. C'est souvent pour cette dernière
raison qu'on l'utilise, d'ailleurs.

Ainsi, si une table t1 possède un champ, f1, avec trois
enregistrements,

tous trois ayant la valeur "a",

t1 ' table
f1 ' champ
"a"
"a"
"a" ' valeurs

SELECT a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
retourne 9 enregistrements,

SELECT DISTINCT a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
retourne 1 enregistrement,

SELECT DISTINCTROW a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
retourne 3 enregistrements ( des 9 premiers, mais, selon ce qui est
sélectionné, on ne conserve, par valeur, qu'au plus un enregistrement par
table impliquée dans la sélection ).

Pareillement, si la table t1 possède "a", "a", "b" (au lieu de trois
enregistrements chacun avec un "a"), les nombres d'enregistrements
retournés

sont de 5, 2 et 3, respectivement (avec ALL, avec DISTINCT et avec
DISTINCTROW).

En effet, si on n'utilise ni DISTINCT, ni DISTINCTROW, implicitement, on
utilise ALL

SELECT ALL a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
est équivalent à
SELECT a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1

Espérant être utile,
Vanderghast, Access MVP

"Daniel" <no@spam.net> wrote in message
news:%23cT%23NuidDHA.3596@TK2MSFTNGP11.phx.gbl...

Salut
J'aimerais savoir l'utilité de distinctrow par rapport a distinct

J'aimerais savoir dans quelle situation il est mieux d'utiliser
distinctrow

au lieu de distinct

Merci

Vous avez filtré cet utilisateur ! Consultez son message

Salut,

Précisions, j'aurais du écrire

"par tableS impliquéeS DANS LE SELECT".

Dans le premier, seule la table a est impliquée, a.f1 fourni une seule
valeur, "a", donc, des 9 enregistrements initiaux, tous produisant "a", je
me limite à un seul par enregistrement initial, ce qui nous laisse 3
enregistrements.

Le second cas est plus illustratif. Le produit cartésien, produire toutes
les combinaisons possibles, fournirait:

provient des energistements numéro
a.f1 b.f1 de a de b
a a 1 1
a a 1 2
a b 1 3
a a 2 1
a a 2 2
a b 2 3
b a 3 1
b a 3 2
b b 3 3

ainsi, la quatrième ligne provient de la combinaison du second
enregistrement de a et du permier enregistrement de b (pour illustration
seulement, en fait, on utiliserait des "signets", ou "bookmarks", ou les
clés primaires).

La jointure interne nous force à ne conserver que ceux où a.f1=b.f1

a.f1 b.f1 de a de b
a a 1 1
a a 1 2
' a b 1 3 ' éliminé, a<>b
a a 2 1
a a 2 2
' a b 2 3 ' éliminé, a<>b
' b a 3 1 ' éliminé, b<>a
' b a 3 2 ' éliminé, b<>a
b b 3 3

Le SELECT ne considère que la table "a". On élimine toutes informations (et
repérages) concernant la table "b".

a.f1 de_a
a 1
a 1
a 2
a 2
b 3

Le DISCTINCTROW connaît qu'il y a deux valeurs, "a" et "b", et de ne
conserver, pour chacune d'elles, qu'un seul cas par enregistrement initial.
C'est un peu comme si on effectuait un "GROUP BY" sur a.f1, et sur le
"repérage de provenance de quel enregistrement de la table a". On se
retrouve donc avec:

a.f1 de_a
a 1
a 2
b 3

où la valeur "a" est encore "double", car elle est dans deux
enregistrements, initialement, dans la table.

La dernière manipulation est d'éradiquer toute trace des "méta données", on
élimine donc nos "signets" qui nous indiquaient la provenance de
l'enregistrement initial, et le résultat est:

a.f1
a
a
b

Évidemment, c'est un cas fabriqué, mais les points importants sont:

- il y a "à quelque part" conservation du "repérage" de la
provenance (utile pour effacer, disons), mais cela pourrait ralentir ou
restreindre les possibilités d'optimisation...
- il n'y a pas plus qu'un enregistrement par enregistrements de(s)
table(s) impliquée(s) dans le SELECT, par tuple (ensemble des champs)
constitué par la sélection (PAS par la jointure). Ceci peut être utile si on
conserve, dans le SELECT, un nombre moindre de tables que celui impliqué
dans la JOINTURE. Si ce point nécessite éclaircissement, prière de le dire
(en réponse, ici), car un exemple qui illustrerait le concept avec détails
pertinents est, à première vue, un peu volumineux: il faut au moins trois
tables jointes, pour n'en conserver que deux dans le SELECT, si on désire
quelque chose de plus "parlant" que l'exemple ci-haut.

Espérant être utile,
Vanderghast, Access MVP

"Michel Walsh" wrote in message
news:%

Salut,

Utiliser DISTINCT dans le sens général d'obtenir un seul
enregistrement

(tous champs confondus), un peu comme le ferait un GROUP BY appliqué sur
tous et chacun des champs sélectionnés.

Utiliser DISTINCTROW, propriétaire à Jet, si on désire qu'au plus un
enregistrement par valeur, tous champs sélectionnés confondus, par table
originalement impliqué, ce qui est généralement le cas pour une requête de
type DELETE sur une jointure, car DISTRINCTROW ne détruit pas la
possibilité

de mettre à jour les enregistrements. C'est souvent pour cette dernière
raison qu'on l'utilise, d'ailleurs.

Ainsi, si une table t1 possède un champ, f1, avec trois
enregistrements,

tous trois ayant la valeur "a",

t1 ' table
f1 ' champ
"a"
"a"
"a" ' valeurs

SELECT a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
retourne 9 enregistrements,

SELECT DISTINCT a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
retourne 1 enregistrement,

SELECT DISTINCTROW a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
retourne 3 enregistrements ( des 9 premiers, mais, selon ce qui est
sélectionné, on ne conserve, par valeur, qu'au plus un enregistrement par
table impliquée dans la sélection ).

Pareillement, si la table t1 possède "a", "a", "b" (au lieu de trois
enregistrements chacun avec un "a"), les nombres d'enregistrements
retournés

sont de 5, 2 et 3, respectivement (avec ALL, avec DISTINCT et avec
DISTINCTROW).

En effet, si on n'utilise ni DISTINCT, ni DISTINCTROW, implicitement, on
utilise ALL

SELECT ALL a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1
est équivalent à
SELECT a.f1 FROM t1 as a INNER JOIN t1 As b ON a.f1=b.f1

Espérant être utile,
Vanderghast, Access MVP

"Daniel" wrote in message
news:%23cT%
Salut
J'aimerais savoir l'utilité de distinctrow par rapport a distinct

J'aimerais savoir dans quelle situation il est mieux d'utiliser
distinctrow

au lieu de distinct

Merci

distinct et distinctrow

6 réponses

Veuillez sélectionner un problème