Discussion :

[mirak63]

salut,

J'ai une table A dont les valeurs doivent être mise à jour quotidiennement.
A la base elle était loadée et entièrement écrasée, mais la modification de la table et le changement de la clef primaire par l'ajout d'une séquence en clef primaire rend l'écrasement total impossible, car on pourrait pas retrouver les mêmes valeurs de séquences qui correspondent à l'ancienne clef primaire.

là ce que je vois comme méthode, c'est de charger tout dans une table Atemp identique à l'ancienne table A, donc sans séquence.
ensuite avec un for dans un procédure, je regarde si la ligne de Atemp existe dans A selon l'ancienne clef, et si elle existe plutot que de vérifier si c'est la même je fais un update directement (à moins que j'y gagne vraiment en perfs), et si elle existe pas je l'ajoute.

mais ça me parait super lourd et innefficace.

[fweiner]

Mirak63

Une chose m'étonne.
Si tes deux tables ont exactement la même définition la fonction de LOAD de Db2 permet d'office de faire de l'INSERT/UPDATE

un peu comme ça si tu fais cela : Ex en IXF :

CONNECT TO mabase USER moi USING monmotdepasse;
IMPORT FROM "c:\source" OF IXF MESSAGES "c:\ImportLog.txt" INSERT_UPDATE INTO monschema.matable;
CONNECT RESET;

Pour le coup cette fonction détecte l'existence d'enregistrements et les mets a jour automatiquement si besoin est.

J'espère t'avoir aidé.

[mirak63]

hum, c'est quoi la différence entre le load et l'import ?

je savais pas qu'il y avait le import

[mirak63]

INSERT_UPDATE
Adds rows of imported data to the target table, or updates existing rows (of the target table) with matching primary keys.

http://publib.boulder.ibm.com/infoce...61%74%65%22%20

en fait je peux pas m'en servir pour ce que je dois faire, car la clef primaire de la table dans laquelle je dois importer n'est pas la même que celle des fichiers de données à importer.

en effet les donénes à importer c'est A,B,C,D avec pour clef A, alors que ma table c'est plutot ID,A,B,C,D , ID étant la clef primaire en séquence qui doit être générée à l'insertion de nouvelles données.

Et je pense pas que je puisse faire un alter primary key, ça serait trop bourrin vu les clef étrangères qui en dépendent ...

Et il est apparement pas possible de dire à import de choisir une clef primaire temporaire pour la commande d'import seulement ...

[fweiner]

[FONT=&quot]Question ? Est ce que ton ID est un champ a incrémentation automatique gérée par le SGBD ?

Si oui alors tu n'as pas à t'en soucier.

Si non, alors je ne vois plus qu'une solution : la programmation; tu peux écrire une procédure sql (par exemple) qui lit ta table d'origine dans un curseur.

Qui teste l'existence de ton enregistrement sans tenir compte de cette nouvelle cle qu'est l'ID, est si tu trouve, de toutes façon tu as récupérer l'ID via ta lecture, Il ne te reste plus qu'a mettre a jour champs par champs.

Si tu n'as pas trouvé ton enreg alors alimente ta zone ID via un select max sur ta table de destination puis tu lance ton écriture avec un test de bonne exécution de ton écriture qui te permet de faire +1 sur ton ID a chaque retour d'un SQLCODE 13 ou -803 (Doublon).

Voila

Pour ma part c'est une réponse possible, savoir si c'est la meilleur, c'est autre chose. En tous cas je la fait en fonction de ce que j'ai compris de tes réponses précédentes. (Mais j'ai un doute)[/FONT]

[mirak63]

si, c'est bon, ta réponse correspond à ce que j'ai mis en place finalement.

tout est loadé dans l'ex table A nommé maintenant A_temp, et ensuite je fais un curseur sur A_temp left outer join A sur l'ex clef primaire commune a A et A_temp appellée IDENT par exemple

ensuite je regarde quand IDENT est à null j'insere les valeurs venant de A_temp dans A en incrémentant la séquence, et si c'est pas null j'update les valeurs champ par champ si ils sont différents.

Là dessus je sais pas si le plus rapide est d'updater la ligne entière ou seulement les champs qui changent