Discussion :

[Brice Yao]

Salut à tous,
Je suis confronté à un pb !
voici ma table: Consultation(matricule, nom, prenoms, datejour, heureentree, heuresortie).
Les données étants générées chaque jour je veux avoir comme resultat de ma consultation un tableau de ce genre:

Datejour1 Datejour2 Datejour3
NomPren1 He11 hs11 He12 hs12 He13 hs13
Nom Pren2 He21 hs21 He22 hs22 He23 hs23
Nom Pren3 He31 hs31 He32 hs32 He33 hs33

avec He=heureentree
Hs=heuresortie
c-à-d pour chaque jour avoir l'heure d'entrée et de sortie de NomPrenoms.

[vplf]

Est ce que tu utilises par hasard access car les requetes croisée sont une spé de access il me semble....(dans ce cas change de forum)
Sinon tu utilises quoi?
vplf

[Brice Yao]

J'utilise une base de données sql server!

[vplf]

J'utilise une base de données sql server!

J'ai réalisé une requete croisée dynamique en access mais je ne connait pas du tout le SQL server.

dsl...

Mais ça se resemble peut etre?

vplf

[SQLpro]

les tableaux croisés ne sont pas des requêtes mais un artifice cométique qui heureusement n'existe pas dans MS SQL Server.
Malheureusement, Microsoft à décidé d'introduire cela dans la version 2005. Voici ce que j'en dit dans un article à paraître :

"
ATTENTION : Si cette technique permet de réconcilier les afficionados d'Access et des tableaux croisés avec SQL Server, tant mieux. Mais ce "truc" possède de très nombreux inconvénients majeurs :

1) aucune conformité aux normes SQL et franchement pas standard : la transformation de valeurs en nom de colonnes est une absurdité et le recours aux crochets pour nommer les colonnes provenant des valeurs n'obéit à aucune logique, ni aucun standard si ce n'est les spécificités de MS SQL Server.

2) même si le plan de requête parait plus simple, il n'est pas certain que l'effort en terme d'E/S soit moindre. En effet l'utilisation d'un tel opérateur empêche en principe l'utilisation des index.

3) toute opération cosmétique grève énormement les performances d'un serveur SQL parce qu'il n'a pas été prévu pour cela, alors qu'un outil de présentation spécialisement conçu à cet effet pourra donner le même rendu en minimisant les ressources.

4) la clause IN de l'opérateur PIVOT n'a pas été rendue générique. En l'occurrence l'écriture très tentant d'une requête du genre :
PIVOT (SUM(VTE_CA) FOR VTE_PERIODE IN (VTE_PERIODE) AS TRIMESTRE
ou encore :
PIVOT (SUM(VTE_CA) FOR VTE_PERIODE IN (SELECT DISTINCT VTE_PERIODE FROM T_VENTE_VTE) AS TRIMESTRE
n'est pas possible. Il faut spécifier "en dur" et connaître d'avance les colonnes !

En conclusion : les opérateurs PIVOT / UNPIVOT revêtent peu d'intérêtn et sont à éviter systématiquement pour qui veut des performances.
"

A +