Discussion :

[StringBuilder]

Bonjour,

J'ai un souci récurrent en SQL, et je me demande s'il n'y a pas une solution "simple" à mettre en place.

Mettons une table des clients (id, code, nom, prenom, etc.)

Je dois m'interfacer avec un autre serveur.

Je récupère donc dans une base tampon toutes les données du serveur distant, puis je fais un différentiel entre ce qui a été modifié, ajouté et supprimé.

Et je recopie les lignes en écart.

Du coup je vais ça à grand coup de INSERT from SELECT.
Et la base distante étant une petite rigolote, des fois j'ai des changements de type sans être notifié, et du jour au lendemain je me retrouve à insérer dans ma table tampon des varchar(50) dans une colonne varchar(10) et ça plante.

Existe-t-il un moyen, qui ne soit pas une usine à gaz (genre pas tester la longueur de chaque colonne une à une) qui permette non pas de planter la requête, mais simplement ignorer les lignes en erreur, soit en alimentant une table de rejet (l'idéal) soit simplement en déclenchant un message d'erreur qui ne soit pas bloquant (et qui ne fasse donc pas échouer le reste de la requête) ?

Car actuellement, je suis obligé de détecter quand ma requête échoue, et mon interface reste complètement bloquée jusqu'à ce que je corrige (ce que je ne peux pas toujours faire dans l'immédiat) et si je détecte mal l'anomalie, je me retrouve avec une table tampon vide, donc mon programme croit qu'il faut vider la table des clients et là c'est tout de suite moins drôle.

La solution alternative consisterait à traiter les lignes 1 à 1 de manière séquentielle... Mais là d'un traitement de 2 minutes plus plusieurs centaines de milliers de clients, on va passer à 4 heures...

L'idéal serait d'avoir une comme un peu comme MERGE sauf qu'au lieu de tester l'existence d'une ligne par exemple pour faire un insert ou update, ce serait de tester l'erreur lors de l'insertion de la ligne, et de faire autre-chose si l'insert échoue.

[TheRussian]

Bonjour,

sur la même problématique, intégrer les données de plusieurs applications dans un seul entrepôt de données avec les contraintes suivantes :
- Pas informer des évolutions/modifications des appli tiers
- Obligation d'intégrer toutes les lignes, les écarts devant être constatés sur les différents reporting à posteriori

==> j'ai opté pour la mise à jour des formats des colonnes dans les procédures d'importation. Et cela n'a pas été si lourd que ça. Je m'attendais à pire

Sinon en jouant avec les TRY .. CATCH https://docs.microsoft.com/fr-fr/sql...h-transact-sql
Il doit y avoir moyen de mettre en place ce mode de fonctionnement non ?

[StringBuilder]

Le TRY CATCH s'applique à la requête entière.

Donc quand je fais un INSERT FROM SELECT qui porte sur des millions de lignes, il suffit d'une seule ligne en erreur pour que toute l'instruction soit arrêtée.

Ceci peut se produire au bout de plusieurs minute ou heures de traitement, c'est donc pas terrible pour ensuite :
- Identifier les quelques lignes qui posent problème
- Il faut rejouer toutes les autres lignes, après une grosse perte de temps

Après effectivement, je pourrais interroger les lignes de la table source, ou parcourir le fichier d'import pour vérifier la taille max des colonnes à l'avance, mais ça fait un peu usine à gaz;

Tant pis Pour le moment on va continuer comme ça… Le prochain coup le client mettra peut-être un peu plus de 3 mois avant de se rendre compte que l'interface est plantée

[TheRussian]

Une solution pourrait-être d'insérer toutes les lignes en tronquant les champs concernés avec la fonction LEFT.
C'est un peu crade comme méthode mais cela permettra de tout charger tout le temps.

Plus propre : Si le but est d'identifier les lignes en erreur et de ne pas les charger peut-être qu'un fonctionnement via un ETL pourrait convenir.
On peut faire des imports et identifier les rejets tout en continuant le chargement des lignes valides.
Tu pourrais avoir un fichier contenant tous les rejets à la fin du traitement.

[tbc92]

Oui, via un ETL, ça insère les bonnes lignes, et ça rejette les mauvaises.

Sinon : Insert into matable select * from autreTable where len(description) <= 10 ;

[StringBuilder]

Merci pour vos réponses

En fait, le but ici c'est de se passer de l'ETL (notamment pour maximiser la vitesse de traitement).

Pour ce qui est des LEFT / LEN, c'est effectivement une piste envisageable.
Seulement le but serait de rendre la longueur du champ dépendante de la longueur physique dans la table.

Un peu comme ce qu'on peut faire dans Oracle quand on crée une procédure stockée : au lieu d'utiliser un type nommé + longueur, on peut indiquer qu'on veut utiliser le même type qu'une colonne d'une table donnée : du coup si la colonne change, la procédure aussi.

C'est un peu le même mécanisme que je cherche à reproduire : qu'à chaque modification ce ne soit pas une usine à gaz à faire évoluer.

Je pense que je vais devoir passer par une génération à la volée du SQL à partir d'un programme autre que mon *.BAT actuel, tant pis