|
Publicité ' | |||||||||||||||||||||||
|
|
#1 | ||
|
Invité de passage
![]() Consultant ERP Inscription : septembre 2012 Messages : 14 ![]() |
Bonjour à toutes et à tous,
N'ayant pas trouvé de sujet correspondant, je sollicite donc la formidable communauté que nous sommes Je dois récupérer deux champs dans deux table différentes et concaténer ensuite ces informations dans un troisieme champs. Je sais récupérer une information d'une table pour l'insérer dans une autre, mais je suis confronté à deux problèmes. Pour info : Je suis en SQL Server. Ma première donnée est un numéro (de facture) sur 4 digit. La deuxième donnée est ce qu'on appelle la souche; en fait un trigramme qui identifie la société qui émet la facture. J'ai une table avec toutes mes factures ( de 0001 à 1500 environ) et une table avec les souches (celle qui m'intéresse est ST1) J'ai créé une table (Z_FULLINVOICEID) dans laquelle je récupère mon numéro de facture (DO_Piece), ma souche (S_INTITULE), et j'ai créé un troisième champ où j'espérai concaténer les deux information (INVOICE_ID). Le premier problème que je rencontre est que je n'arrive pas à récupérer uniquement la souche qui m'intéresse et l'insérer en face de chaque numéro de facture dans ma table Z_FULLINVOICEID ( DO_Piece|S_Intitule 654 | ST1 655 | ST1 etc SQL me renvoie systématiquement toutes les souches dans l'ordre de la table d'où elles viennent ... DO_Piece | S_Intitule 654 |ST1 655 |ST2 656 |ST3 J'ai réussi a contourner le problème mais c'est pas propre puisque j'insère en "dur" l'info de la souche alors qu'elle est présente dans le système ... Le deuxième souci, c'est que je n'arrive pas a construire ma requête pour concaténer les deux info dans le 3ème champs que j'ai créé. j'ai bien essayé ça, mais visiblement ma syntaxe SQL n'est pas bonne ... Code :
Merci à vous tous ! |
||
|
|
00
|
|
|
#2 |
![]() ![]() Alain Ingénieur d'études décisionnel Inscription : mai 2002 Messages : 4 877 ![]() |
L'opérateur de la concaténation en SQL est ||, pas +.
__________________
Modérateur Langage SQL N'oubliez pas le bouton et pensez aux balises [code]Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
|
|
|
00
|
|
|
#3 |
|
Invité de passage
![]() Consultant ERP Inscription : septembre 2012 Messages : 14 ![]() |
Bonsoir,
en SQL Server c'est explicitement '+' en fait j'ai aussi essayé || et cela ne fonctionne pas non plus... |
|
|
00
|
|
|
#4 |
|
Membre Expert
![]() Analyste / Programmeur / DBA Inscription : juillet 2006 Messages : 1 935 ![]() |
Peut-on avoir le DDL des deux tables concernées ?
(cfr charte de postage)
__________________
Kropernic (anciennement Griftou). |
|
|
00
|
|
|
#5 |
|
Invité de passage
![]() Consultant ERP Inscription : septembre 2012 Messages : 14 ![]() |
Oups j'avais raté ce point.
Dès que notre serveur de test est online, je récupère cela et je vous le post. Merci ! |
|
|
00
|
|
|
#6 | ||||||
|
Invité de passage
![]() Consultant ERP Inscription : septembre 2012 Messages : 14 ![]() |
J'ai récupérer les 3 tables. Pour info, il s'agit des base de données d'un système SAGE L100.
La table avec mes factures : Code :
Code :
Code :
|
||||||
|
|
00
|
|
|
#7 | ||||
|
Membre Expert
![]() Analyste / Programmeur / DBA Inscription : juillet 2006 Messages : 1 935 ![]() |
Plusieurs remarques :
1 : OMG la table à rallonge ! (mais bon, je crois qu'on est tous passé par là un jour ou l'autre). Un article intéressant 2 : Dans la table que tu as créés, pourquoi utiliser le type nchar ? Tu attends des caractères autres que latins ? (genre idéogrammes) 3 : Toujours dans cette table, même si toutes les colonnes étaient en char, tu veux concaténer deux colonnes char(10) dans une autre colonne char(10). 10+10 = ...... 10 ? Cela fait fait 20 chez moi. Même si en théorie, pour des raisons x ou y la somme des longueurs des 2 colonnes ne devrait jamais dépasser 10, en pratique, vu la DB, rien ne l'interdit. Donc gaffe à ça aussi. 4 : J'avais pas spécialement fait gaffe à la première lecture mais en relisant la requête que tu montres dans ton premier message, est-ce normal de faire un insert plutot qu'un update ? Au vu de ta requête, si je comprends bien, tu as déjà inséré les 2 infos de bases et tu veux gérer l'info devant se trouver dans la 3e colonnes. J'aurais plutôt fait quelque chose dans ce genre-là : Code :
Code :
Je vais m'arrêter là. Si je vois autre chose, j'ajouterai
__________________
Kropernic (anciennement Griftou). |
||||
|
|
00
|
|
|
#8 |
|
Invité de passage
![]() Consultant ERP Inscription : septembre 2012 Messages : 14 ![]() |
Merci beaucoup pour les conseils
Pour la longueur de la table F_DOCENTETE, c'est malheureusement du SAGE out of the box, donc je ne peux pas y toucher. Par contre, en continuant à me triturer les méninges sur ce problème, j'ai changer quelques points, que je suis heureux de retrouver dans tes commentaires. 1) la nature de mes champs était mal définie. J'ai choisi varchar qui a l'air plus adapté. 2) en effet un UPDATE est plus adapté qu'un insert ... faut que je fasse attention à ma logique BDD des fois ... 3) j'ai testé ma requete avec un UPDATE, et la bonne syntaxe de concatenation ( || ne fonctionne pas du tout en MS-SQL, évidemment) et bien sur, cela fonctionne. 4) pour répondre à ta question, je dirais que je fais avec mes connaissance, je ne sais pas (pas encore) une colonne ou un champs calculé ... Pour résumé, le schema auquel j'avais pensé était celui la : 1) créer la table Z_FULL_INVOICE_ID 2) récupérer le champs DO_Piece de la table F_DOCENTETE 3) Récupérer la valeur de la souche S_Intitule de la table P_SOUCHEVENTE (plutot que de coller en dur sa valeur dans la table) 4) concaténer l'ensemble dans le champs INVOICE_ID. Vu que j'ai une quinzaine de sociétés a traiter, j'aurai voulu pouvoir scripter cela dans le bon sens, et dérouler l'ensemble sur toutes mes bases. Au final, il ne me reste qu'un point non résolu, et un détail que je devrais pouvoir résoudre tout seul. Le point, c'est récupérer la bonne souche depuis P_SOUCHEVENTE (bien qu'en y réfléchissant en même temps que j'écris, je dois pouvoir faire un Select avec un IS NOT NULL quelque part et ça devrait fonctionner) - le détail, c'est qu'il me concatène aussi les espaces du champs S_Intitule, mais je crois avoir trouvé une parade. Vivement 2013 que je fasse enfin ma formation SQL ...
|
|
|
00
|
|
|
#9 |
|
Membre Expert
![]() Analyste / Programmeur / DBA Inscription : juillet 2006 Messages : 1 935 ![]() |
Pour "supprimer" des espaces en début ou fin d'une donnée littérale, il y a les fonctions LTRIM et RTRIM qui retirent respectivement les espaces à gauche et à droite de la chaîne de caractère (L pour Left et R pour Right, ça aide à retenir).
Pour récupérer la bonne souche, cela devrait, je pense, se faire automatiquement avec la bonne condition de jointure (dans le 2e bout de code que j'ai posté, c'est la partie en gris qu'il faut remplacer). J'avoue ne pas avoir pris le temps de chercher dans les deux tables sources que tu donnes lesquelles de leurs colonnes servaient de clefs étrangères de l'une vers l'autre.
__________________
Kropernic (anciennement Griftou). |
|
|
00
|
|
|
#10 |
|
Invité de passage
![]() Consultant ERP Inscription : septembre 2012 Messages : 14 ![]() |
Le problème c'est que je ne vois pas comment faire ma jointure entre ma table F_DOCENTETE et P_SOUCHEVENTE, elles n'ont aucuns aucun champs en commun ... mais je vais bien trouver une solution
Merci énormément, en tout cas, je sais maintenant que je suis sur la bonne voie!! Bonnes fêtes de fin d'années à tous ! |
|
|
00
|
|
|
#11 | |
|
Membre Expert
![]() Analyste / Programmeur / DBA Inscription : juillet 2006 Messages : 1 935 ![]() |
Citation:
Typiquement, si on prend l'exemple des clients et de leur facture, on aura, en simplifiant à outrance, 2 tables. Une table T_CLIENT_CLI avec la colonne CLI_ID qui est un entier auto-incrémenté (+ d'autres colonnes pour les infos sur le clients) et une table T_FACTURE_FAC avec la colonne FAC_ID qui est un entier auto-incrémenté (+ d'autres colonnes pour les infos sur la facture) et une colonne CLI_ID pour stocker l'id du client à qui "appartient" la ligne. Maintenant, en pratique, rien ne m'empêche si je deviens fou de nommer la colonne CLI_ID de la table T_FACTURE_FAC totalement autrement. Le problème, c'est qui si quelqu'un doit passer après, il va avoir du mal à trouver facilement les jointures à mettre en oeuvre. N.B. : Ce n'est pas tout à fait vrai car même avec des noms tarabiscotés, il y a normalement une contrainte de type FOREIGN KEY à définir qui pourra lui permettre de retrouver facilement les noms des colonnes. Dans Management Studio, en faisant un clic droit sur la table et en choisissant Script Table as > CREATE To > New Query Editor Window (désolé, je l'ai en anglais), on retrouve ces contraintes vers la fin du script.
__________________
Kropernic (anciennement Griftou). |
|
|
|
00
|
|
|
#12 |
|
Invité de passage
![]() Consultant ERP Inscription : septembre 2012 Messages : 14 ![]() |
J'ai vu ça aussi (je l'ai aussi en anglais) je vais regarder de plus prêt.
Merci encore ! |
|
|
00
|
Copyright © 2000-2013 - www.developpez.com