Rechercher diff et update LONG

Bonjour,

J'ai des tables de référentiel alimentées par loader avec des csv provenant d'Excel (remplis par des utilisataires fonctionnels) en utilisant le processus : delete toutes les données des tables loadées + sqlloader

Ceci marche parfaitement mais aujourd'hui grand vent de panique : on doit absolument fonctionner par mise à jour.
Il faut donc repérer les diff entre les fichiers csv qu'on veut charger et les données en base.

J'ai plusieurs instances à ma dispo sur l'environnement de dév et donc je compare les champs entre les tables grace à un DBLink (je sais pour les perfs mais il s'agit de dév et ce sont des petites tables de référentiel)
Pour la plupart des champs, il n'y a guère de soucis, mais pour les long comment faire ?

Comment donc repérer la différence sur des champs long, le long étant interdit en sql dans une clause where ?
Une fois le diff établi, comment mettre à jour ce champs long ? L'update ne marche pas ?
Merci de votre aide car je suis dans la panade !!

pourquoi ne pas faire une table externe basée sur se fichier et faire l'update des différences ?

Pour le LONG, faut passer par du CLOB :?

Ceci dit, faudrait qu'on m'explique l'intérêt de se casser la tête comme ça pour éviter de mettre à jour avec les mêmes valeurs :koi:

Je ne comprends pas bien la réponse
Le soucis étant justement de générer uniquement l'update sur les différences

Puisque j'ai 2 instances, dans l'une je mets les données de prod, dans l'autre les nouvelles données et comme ca je ne récupère que le diff pour faire l'update

Comment générer ce diff sur des champs long ?
Et comment updater du long ?

Les données dans cse champs long contiennent des retour chariot et font plus de 32767 caractères

En processus d'alimentation de données, il est vraiment nécessaire d'avoir une (voire deux) étape intermédiaire entre vos sources et vos cibles.
Celà laisse du temps pour faire des contrôles, gérer des rejets, analyser les différences ou encore effectuer des calculs.

Pour votre problème, il est parfois plus rapide de faire un delete + insert qu'un update, comme ça vous n'avez pas à comparer champ à champ vous voyez juste que la donnée a été renvoyée et vous la remplacer (celà nécessite une désactivation temporaire de vos clefs étrangères, s'il y en a). Maintenant c'est au cas par cas.

N'ayant pas accès à la prod, il faut que je "prédigère" les infos pour faire la livraison
Et dans cette prédigestion, je peux faire l'analyse du diff pour générer moi meme à la mano les ordres update sur les bonnes lignes
Il est hors de question de faire un chargement en parralèle et de faire un traitement de comparaison

Citation:

---

Pour votre problème, il est parfois plus rapide de faire un delete + insert qu'un update

---

C'est exactement ce que je faisais et qui marchait très bien
Seulement, suite à un vent de panique, il est devenu interdit de faire du delete sur des données référentielles en prod
D'ou mon soucis

ma remarque remettait en cause le besoin ? Pourquoi faire un update des lignes qui diffèrent et pas toutes les lignes puisque l'update n'aura pas d'incidence si les données ne change pas :?

Sinon, soit tu changes le long en CLOB soit tu ne compares pas ce type de colonne :)

Oui moi aussi j'ai du mal à comprendre le besoin, mais c'est pas moi qui décide... :(

J'ai trouvé une solution.
- comme j'ai 2 instances dispo, j'ai l'1 avec les anciennes données et je charge l'autre avc les nouvelles
- je crée une copie de la table avec long dans une table en CLOB
- j'utilise la procédure DBMS_LOB.COMPARE pour savoir quel(s) id ont changé
- je supprime ces lignes
- je load uniquement ces lignes

C'est pas super industrialisé mais pour l'instant, j'ai pas mieux.
Merci