Hello all

J'ai 2 tables :

Table 1 :

id     value
8      kikoo
12    lol
31    asv
41    kikoo

Table 2 :

id     value
1      kikoo
2      lol
3      asv
4      kikoo

La table 2 est en fait identique à la table 1, sauf que les id ont été renumérotés suite à une migration. Du coup, ces id étant aussi liés à des clés étrangères d'autres tables, toutes mes relations sont foutues, normal.

J'ai donc voulu créer une table de correspondance entre les anciens id et les nouveaux, afin d'alimenter mes tables dépendantes correctement, via la requête suivante :

CREATE TABLE #temp(old INT, new INT)
INSERT INTO #temp SELECT o.id, n.id FROM table1 o INNER JOIN table2 n ON o.value = n.value 
SELECT * FROM #temp

J'obtiens ceci

old    new
8       1
12     2
31     3
41     1

le probleme saute donc aux yeux : sur la 4eme ligne, pour l'ancien id 41, j'ai 1 comme nouvel id au lieu de 4 et je suis donc dans le caca

un cador pour m'aider à dépatouiller ça ?

Merci les gros

edit: j'utilise SQL Server 2005

Pourquoi t'as pas conservé les id lors de la migration ? Y'avait des données déjà présentes ?

ben oui

ok ; sinon je t'aurais dit d'utiliser IDENTITY_INSERT mais là je vois pas trop

T'as essayé de jouer avec 'INTERSECT'?

ben si la base d'origine avait été vide, j'aurais même pas créé de topic hein
faut m'aider hein, sinon je dors au bureau

ah tiens, spas con ça, j'y avais pas pensé
je regarde ça de suite
merci chef

Avec Oracle, tu aurais pu jouer avec rownum ou row_number(). Avec SQL Server, tu as p-ê l'équivalent, non ?

Je suis pas trop sûr de moi, mais à la base, ça reproduirait pas ce qu'il s'est passé ça ?
 
Parceque du coup t'as même pas besoin de lire tab2 ^^
 

SELECT ROW_NUMBER() over(ORDER BY id), id, value
FROM tab1;

vi justement ^^

SELECT ROW_NUMBER() over(ORDER BY id), id, value
FROM tab1;

rooo ptain, tu sais que je t'aime toi ?

C'est le B.A.BA des fonctions analytiques.
Quand je disais que c'était vachement utile

pis ça fait découvrir à quel point c'est utile le copier/coller, parceque la syntaxe...

Pour ton exemple, ça va, c'est facile, mais il y a d'autres cas qui sont de grosses prises de tête, ouais. De toute façon, la syntaxe de SQL est à mon avis son gros point faible. Ils ont voulu faire un pseudo langage naturel pour le rendre accessible aux non programmeurs, le résultat est qu'elle est extrêmement rigide et difficile à utiliser, à mon goût. La syntaxe impossible à mémoriser des fonctions analytiques est la conséquence directe de la syntaxe du SQL, langage qui d'évidence n'a jamais été prévu pour être extensible.
Les langages fonctionnels traditionnels, au contraire, sont flexibles et leur syntaxe est régulière et mémorisable.