Copie d'une colonne A vers colonne B [Résolu]

[afrodje]

Bonjour,

J'essaie de copier la colonne T1.tarif vers la colonne T3.total_a_payer

Requête Table A

Code :

1
2
3
4
5
6
SELECT T1.facture,sum(T1.tarif) AS tarif
FROM	Facture_entete  AS T2
INNER JOIN  Table_tarif AS T1
ON T1.tarif= cast(T2.numero_facture AS int)
GROUP BY T1.facture
ORDER BY T1.facture ASC

Requête Table B

Code :

1
2
SELECT T3.numero_facture, T3.total_a_payer
FROM dbo.Facture_entete T3

Voici un aperçu de la requête Table A :

Code :

1
2
3
4
5
6
7
11252288	964
11252289	964
11252290	2892
11252291	964
11252292	1927
11252293	964
11252294	964

Voici un aperçu de la requête Table B :

11252288 NULL
11252289 NULL
11252290 NULL
11252291 NULL
11252292 NULL
11252293 NULL
11252294 NULL

Après pas mal de tests d'UPDATE, je n'y arrive pas

Merci d'avance.

[dehorter olivier]

bonjour

Utilises une syntaxe du type

Code :

1
2
3
4
5
6
UPDATE T3.total_a_payer = (SELECT sum(T1.tarif) AS tarif
                                                   FROM Facture_entete  AS T2
                                                       INNER JOIN  Table_tarif AS T1
                                                         ON T1.tarif= cast(T2.numero_facture AS int 
WHERE T1.facture = t3.numero_facture)
FROM dbo.Facture_entete T3

Mais pourquoi avoir cette colonne "total_a_payer", alors qu'une requête te fournis le résultat à la volée ?

[CinePhil]

Euh... petite erreur dans ta requête il me semble Olivier !
Je ferais plutôt comme ça :

Code :

1
2
3
4
5
6
7
8
9
10
UPDATE T3
INNER JOIN
(
    SELECT T1.facture, SUM(T1.tarif) AS tarif
    FROM Facture_entete  AS T2
    INNER JOIN Table_tarif AS T1
        ON T1.tarif = cast(T2.numero_facture AS int)
    GROUP BY T1.facture
) A ON A.facture = CAST(T3.numero_facture AS INT)
SET T3.total_a_payer = A.tarif

Mais pourquoi avoir cette colonne "total_a_payer", alors qu'une requête te fournis le résultat à la volée ?

Et pourquoi mettre un numéro de facture dans une colonne de type entier ?
Tu comptes additionner les numéros de facture ?
Tout ce qui est numéro, référence, matricule, code... ne faisant jamais l'objet de calculs doit être mis dans des colonnes CHAR ou VARCHAR !

[dehorter olivier]

oups

ah oui joli (je ne dois pas être du matin , allez café !)

[afrodje]

Envoyé par dehorter olivier

bonjour
Mais pourquoi avoir cette colonne "total_a_payer", alors qu'une requête te fournis le résultat à la volée ?

La requête 1 s’exécute sur un datawarehouse, et l'autre sur une base de "travail", donc pour optimiser le flux (et le temps d’exécution), je vais effectuer cette copie hors activité.

Envoyé par CinePhil

Euh... petite erreur dans ta requête Olivier !
Je ferais plutôt comme ça :

Code :

Je regarde cette requête de suite.

[afrodje]

Envoyé par CinePhil

Et pourquoi mettre un numéro de facture dans une colonne de type entier ?
Tu comptes additionner les numéros de facture ?
Tout ce qui est numéro, référence, matricule, code... ne faisant jamais l'objet de calculs doit être mis dans des colonnes CHAR ou VARCHAR !

Pas vu cette remarque

Je reprends à la base.
Notre base datawarehouse est issu de notre ERP.
Le champ du numéro de facture est un entier. Nous avons donc laissé les types de donnée par défaut...

Mais effectivement, je suis d'accord avec toi. Dans ma base de travail, ce champ est bien un VARCHAR

[afrodje]

Envoyé par CinePhil

Euh... petite erreur dans ta requête il me semble Olivier !
Je ferais plutôt comme ça :

Code :

J'ai une erreur... (sous SQL server)

Serveur*: Msg 156, Niveau 15, État 1, Ligne 3
Syntaxe incorrecte vers le mot clé 'INNER'.
Serveur*: Msg 170, Niveau 15, État 1, Ligne 10
Ligne 10 : syntaxe incorrecte vers 'A'.

A quoi sert l'alias A?

[CinePhil]

Je pense que c'est dû au fait que j'ai utilisé l'alias T3 de ta seconde requête au lieu du nom de la table facture_entete !
Correction :

Code :

1
2
3
4
5
6
7
8
9
10
UPDATE Facture_entete T3
INNER JOIN
(
    SELECT T1.facture, SUM(T1.tarif) AS tarif
    FROM Facture_entete  AS T2
    INNER JOIN Table_tarif AS T1
        ON T1.tarif = cast(T2.numero_facture AS int)
    GROUP BY T1.facture
) A ON A.facture = CAST(T3.numero_facture AS INT)
SET T3.total_a_payer = A.tarif

Ou alors, vu qu'il y a aussi une erreur de syntaxe près de A, peut-être SQL Server nécessite t-il AS pour tous les alias ?

Code :

1
2
3
4
5
6
7
8
9
10
UPDATE Facture_entete AS T3
INNER JOIN
(
    SELECT T1.facture, SUM(T1.tarif) AS tarif
    FROM Facture_entete  AS T2
    INNER JOIN Table_tarif AS T1
        ON T1.tarif = cast(T2.numero_facture AS int)
    GROUP BY T1.facture
) AS A ON A.facture = CAST(T3.numero_facture AS INT)
SET T3.total_a_payer = A.tarif

A quoi sert l'alias A?

Comme je fais une jointure avec une sous-requête, il faut bien "aliasser" cette sous-requête pour écrire la condition de jointure !

Notre base datawarehouse est issu de notre ERP.
Le champ du numéro de facture est un entier. Nous avons donc laissé les types de donnée par défaut...

Encore un ERP mal modélisé ! C'est lequel ?

[afrodje]

Envoyé par CinePhil

Encore un ERP mal modélisé ! C'est lequel ?

JD Edwards sous AS400.

[afrodje]

Merci pour les explications.

Cependant c'est assez bizarre... avec ou sans le AS, SQL server ne reconnait pas l'UPDATE.


Avec les 2 AS :

Serveur*: Msg 156, Niveau 15, État 1, Ligne 1
Syntaxe incorrecte vers le mot clé 'as'.
Serveur*: Msg 156, Niveau 15, État 1, Ligne 9
Syntaxe incorrecte vers le mot clé 'AS'.

Sans les 2 AS :

Serveur*: Msg 170, Niveau 15, État 1, Ligne 1
Ligne 1 : syntaxe incorrecte vers 'T3'.
Serveur*: Msg 170, Niveau 15, État 1, Ligne 9
Ligne 9 : syntaxe incorrecte vers 'A'.

[CinePhil]

Ça voudrait dire que SQL Server n'autorise pas les alias dans les UPDATE ?
Ou même les jointures car alors je ne vois pas comment faire avec la sous-requête !

Ou alors essaie comme ça avec des données test :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
UPDATE Facture_entete 
SET T3.total_a_payer = 
(
    SELECT tarif
    FROM
    (
        SELECT T1.facture, SUM(T1.tarif) AS tarif
        FROM Facture_entete  AS T2
        INNER JOIN Table_tarif AS T1
            ON T1.tarif = cast(T2.numero_facture AS int)
        GROUP BY T1.facture
    ) A
)
WHERE CAST(Facture_entete.numero_facture AS INT) = A.facture

Mais je trouve ça beaucoup plus lourd comme écriture de requête !

[Jean.Cri1]

C'est peut etre plutot comme SYBASE qui n'autorise pas les tables dérivées dans le where d'un update

[Waldar]

On peut déjà commencer par la version simple :

Code :

1
2
3
4
UPDATE Facture_Entete AS T2
   SET T2.total_a_payer = (SELECT SUM(T1.tarif)
                             FROM Table_tarif AS T1
                            WHERE T1.facture = cast(T2.numero_facture AS int))

Attention celle-ci mettre systématiquement à jour toute la table Facture_Entete, mais je n'ai pas assez d'éléments ici pour appliquer un bon filtre.

Envoyé par CinePhil

Et pourquoi mettre un numéro de facture dans une colonne de type entier ?
Tu comptes additionner les numéros de facture ?
Tout ce qui est numéro, référence, matricule, code... ne faisant jamais l'objet de calculs doit être mis dans des colonnes CHAR ou VARCHAR !

Pas entièrement d'accord avec ce propos.

En ce qui concerne les numéros de factures (ou les identifiants au sens large), de très nombreuses applications les gèrent avec des entiers auto-incrémentés.
Il n'y a alors aucune raison de les transformer en varchar, même si on ne va pas faire d'opération mathématique dessus : ça consomme plus de place, ça réduit la performance des index, ça oblige à des conversions forcément coûteuses.

[afrodje]

Envoyé par CinePhil

Code :

Mais je trouve ça beaucoup plus lourd comme écriture de requête !

Toujours une erreur, que ce soit avec ou sans le "AS" sur A

Serveur*: Msg 107, Niveau 16, État 2, Ligne 1
Le préfixe de colonne 'A' ne correspond ni au nom de table ni au nom d'alias utilisés dans la requête.

Surement pas compatible avec notre version de SQL server 2000... (bon ok, une migration vers 2005 est prévu!)

[CinePhil]

Envoyé par Waldar

En ce qui concerne les numéros de factures (ou les identifiants au sens large), de très nombreuses applications les gèrent avec des entiers auto-incrémentés.
Il n'y a alors aucune raison de les transformer en varchar, même si on ne va pas faire d'opération mathématique dessus : ça consomme plus de place, ça réduit la performance des index, ça oblige à des conversions forcément coûteuses.

Mais l'identifiant auto-incrémenté ne doit servir qu'à la salade interne du SGBD, notamment dans les jointures, et éventuellement comme identifiant masqué à l'utilisateur dans les programmes. Un identifiant auto-incrémenté n'a aucune signification et est invariable alors que, pour des raisons diverses (filialisation ou intégration de filiale, changement de codification...), un numéro, un code, une référence... peuvent changer de forme (aujourd'hui numérique, demain alphanumérique), voire de valeur.

"Allo, vous avez fait une grosse erreur sur la facture 8225 ! Il y a un zéro en trop !
- Oups, Effectivement ! Je vous corrige ça et je vous renvoie une facture 8225/A qui annule et remplace la 8225."
=>Impossible en utilisant l'identifiant auto-incrémenté comme numéro de facture.

"On doit intégrer dans notre ERP les données de gestion de la nouvelle filiale que le patron vient d'acheter. Problème : ils ont les mêmes numéros de factures que nous. Comment on fait ?"
=>Impossible en utilisant l'identifiant auto-incrémenté comme numéro de facture.

"On doit intégrer dans notre ERP les données de gestion de la nouvelle filiale que le patron vient d'acheter. Problème : ils ont des numéros de factures alphanumériques. Comment on fait ?"
=>Impossible en utilisant l'identifiant auto-incrémenté comme numéro de facture.

Je pourrais sans doute multiplier les exemples...

Le corollaire de l'article de SQLPro sur les clés auto-incrémentées est que celles-ci ne doivent servir que de clés primaires et être référencées dans les clés étrangères. Rien d'autre !

[afrodje]

Envoyé par Waldar

On peut déjà commencer par la version simple :

Code :

Attention celle-ci mettre systématiquement à jour toute la table Facture_Entete, mais je n'ai pas assez d'éléments ici pour appliquer un bon filtre.

La requête fonctionne correctement.
J'ai rajouté un WHERE pour ne pas mettre jour à chaque fois

Code :

WHERE Facture_Entete.total_a_payer = ''

Envoyé par Waldar

Pas entièrement d'accord avec ce propos.
En ce qui concerne les numéros de factures (ou les identifiants au sens large), de très nombreuses applications les gèrent avec des entiers auto-incrémentés.
Il n'y a alors aucune raison de les transformer en varchar, même si on ne va pas faire d'opération mathématique dessus : ça consomme plus de place, ça réduit la performance des index, ça oblige à des conversions forcément coûteuses.

Par contre, je ne suis pas pour les identifiants (facture, BL, commande,....) avec la clé autoincrément. (je rejoins l'avis de CinéPhil).
Les identifiants entier permet de simplifier le développement (pas de test si existe déjà, index...), c'est vrai mais peut brider l'application si un imprévu arrive (exemples déjà cités)
De plus, tu trouveras le numéro de facture par exemple "122". 5 ans après tu trouveras une facture "8751874".
Trop de différence en nombre de caractère...

Pour ma part, un numéro avec préfixe + date + heure + incrément sur 3 ou 4 digits permet d'avoir toujours la même structure
(BL201109150002, permet d'avoir aussi des infos sans même interroger l'ERP)

[Waldar]

Envoyé par CinePhil

Mais l'identifiant auto-incrémenté ne doit servir qu'à la salade interne du SGBD, notamment dans les jointures, et éventuellement comme identifiant masqué à l'utilisateur dans les programmes.

Mais soit j'ai rêvé soit ici on parle bien d'un numéro de facture permettant de faire des jointures ?

Envoyé par afrodje

Pour ma part, un numéro avec préfixe + date + heure + incrément sur 3 ou 4 digits permet d'avoir toujours la même structure
(BL201109150002, permet d'avoir aussi des infos sans même interroger l'ERP)

Oui, je n'ai aucun problème avec ceci à condition que ce ne soit pas ce code qui soit référencé dans les autres tables.

[afrodje]

Envoyé par Waldar

Oui, je n'ai aucun problème avec ceci à condition que ce ne soit pas ce code qui soit référencé dans les autres tables.

Bien sur que non, règle des clés étrangères

[CinePhil]

Envoyé par Waldar

Mais soit j'ai rêvé soit ici on parle bien d'un numéro de facture permettant de faire des jointures ?

Si on parle d'un numéro de facture, on parle d'un truc signifiant qui sera imprimé sur la facture physique envoyée au client et lui servira de référence en cas de réclamation ou pour accompagner son paiement. Il ne s'agit alors pas d'un [u]identifiant[/iu] de facture, clé primaire de la table des factures, sans signification et jamais montré à l'utilisateur.

Or, justement, ce que je critique, c'est qu'il semble bien que nous soyons ici en présence d'un identifiant auto-incrémenté qui sert de numéro de facture physique.