Deleted Debug

Bonjour,
Il y a différentes approches, cela dépend du type de traitement sur lequel vous travaillez (mapping, process, webservices...)
La vue Statistiques est souvent utile pour vérifier combien de données sont manipulées.
Les requêtes générées peuvent être consultées dans la vue Step Details, très utile quand on veut voir ce que fait concrètement un mapping, par exemple.
N'hésitez pas à ajouter des actions dans vos process, en alimentant des variables ou pourquoi pas des fichiers de logs...

Je ne vois pas à quels fichiers vous faites référence, par quel type de process sont-ils produits ? Où les trouvez-vous ? Que contiennent-ils ?

OK merci pour l'explication du contexte.
Concernant les erreurs et problèmes remontés par les utilitaires natifs des technologies (TPT pour teradata, BULK pour sqlserver, sqlldr pour Oracle, etc....), une bonne manière d'investiguer consiste à essayer de faire fonctionner l'utilitaire "hors contexte stambia".
Cela permet généralement d'identifier la donnée ou le paramètre de chargement qui fait défaut. Et s'il s'avère que cette donnée / ce paramètre est mal généré par Stambia, alors informer le Support pour faire évoluer le template (ou autre composant Stambia).
En espérant que cela vous aidera.

Souvent, réduire le fichier de données à traiter (faire passer une seule ligne dans un premier temps), permet de valider que l'utilitaire est bien configuré (ou pas).
Puis petit à petit injecter plus de lignes... pour voir si la limite provient du nombre de lignes.

Si quelques lignes passent bien, il y a aussi l'approche dichotomique (réduire de moitié le périmètre de données pour isoler les données qui ne passent pas).

Dans ce cas précis, ce serait la commande générée dans la variable TPT_COMMAND.

Dans la capture d'écran je vois qu'un code TPT10510 est remonté par l'utilitaire.
Il n'y a pas beaucoup de résultats google pour ce code d'erreur. Peut être que le support Teradata pourra vous éclairer davantage.