Erreur copy 2200 dans le pipeline de données Azure Synapse. Erreur de mappage du type de connecteur AzurePostgreSql pour BigDecimal et NpgsqlDecimal

Question

Erreur copy 2200 dans le pipeline de données Azure Synapse. Erreur de mappage du type de connecteur AzurePostgreSql pour BigDecimal et NpgsqlDecimal

Vincent Labrecque 35

Nous avons un cycle ETL quotidien qui s'exécute sur Azure Synapse. Il copie les données d'une base de données PgSQL vers un pool SQL sans serveur.

Depuis vendredi, elle a échoué à chaque exécution. L'activité de copie de table échoue avec le message d'erreur suivant :

{ "errorCode": "2200", "message": "Une panne s'est produite côté « Source ». ErrorCode=UserErrorAzurePostgreSqlNpgsqlParseParamError,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=parse param error for type:Microsoft.Connectors.AzurePostgreSql.TypeMapping.BigDecimal.NpgsqlDecimal,value:System.Decimal,Source=Microsoft.Connectors.AzurePostgreSql,''Type=System.FormatException,Message=Le format de la chaîne d'entrée est incorrect.,Source=mscorlib,'", "failureType": "UserError", "target": "ACT_MT_COPY", "details": [] }

Certaines de mes tables fonctionnent, mais d'autres non. Les tableaux contenant des colonnes décimales fonctionnent, et certains non. Je ne parviens pas à en déterminer la cause. Cela ressemble à une mauvaise mise à jour de Microsoft.

Pilladi Padma Sai Manisha 11,715 Points de réputation Personnel externe de Microsoft Corporation Modérateur

2025-11-27T05:16:56.03+00:00

Hi Vincent Labrecque,
I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.
Vincent Labrecque 35 Points de réputation

2025-12-01T15:31:50.3566667+00:00

Hi @Pilladi Padma Sai Manisha , I have replied to your last comment. Thank you
Mamadou SIDIBE 0 Points de réputation

2025-12-08T16:35:02.2733333+00:00

Bonjour,

Après échange avec une personne du support Microsoft, nous avons pu confirmer que le problème rencontré avec le composant Copy Data et le connecteur PostgreSQL provient d’un bug présent dans les versions récentes du Self-Hosted Integration Runtime (SHIR) — notamment les versions 5.60 et 5.55 — qui n’arrivent pas à lire correctement les valeurs décimales. Le bug est connu de l’équipe produit, un correctif est prévu, mais il n’y a actuellement aucune date de résolution (ETA).

De notre côté, nous avons mis en place une solution de contournement qui fonctionne :

Désinstallation de la version 5.60,

Installation de la version 5.22 (téléchargée depuis le site officiel Microsoft), → Cette version fonctionne correctement et permet d’exécuter les copies de données sans erreur.

Je confirme donc que la version 5.22 fonctionne dans notre cas comme solution temporaire. Nous restons en attente d’une version plus récente corrigée, et Microsoft nous informera dès qu’un fix sera disponible.

Réponse acceptée par l’auteur(e) de la question

Pilladi Padma Sai Manisha 11,715 Personnel externe de Microsoft Corporation Modérateur

Bonjour Vincent Labrecque ,

Merci d'avoir contacté Microsoft Q&A !
Je traduis ceci de l'anglais, veuillez donc excuser les éventuelles erreurs grammaticales.

Merci d'avoir signalé ce problème et pour la description détaillée des échecs de votre processus ETL dans Azure Synapse.

Votre cycle ETL, qui copie les données de PostgreSQL vers un pool SQL sans serveur dans Synapse, échoue pour les tables contenant des colonnes décimales. L'erreur fait référence à un problème d'analyse syntaxique dans le connecteur Azure PostgreSQL lors de la gestion des valeurs BigDecimal/NpgsqlDecimal. Nous constatons des cas similaires depuis mi-novembre 2025.

Il s'agit d'une régression connue du connecteur Azure PostgreSQL V2, récemment introduit, qui affecte la façon dont les types décimaux et numériques (BigDecimal/NpgsqlDecimal) sont analysés entre PostgreSQL et .NET System.Decimal. Notre équipe d'ingénierie produit travaille activement à la résolution de ce problème.

Étapes recommandées pour le dépannage et les solutions de contournement :

Vérifier l’alignement des colonnes décimales :

Assurez-vous que toutes les colonnes décimales de PostgreSQL (source) et du pool SQL (destination) correspondent en termes de précision et d’échelle. Des incohérences peuvent entraîner des erreurs d’analyse lors du déplacement des données.

Consulter les problèmes connus :

Veuillez consulter la liste des problèmes connus d’Azure Synapse Analytics pour connaître les bogues, les mises à jour ou les solutions de contournement pertinents.

Valider la configuration de l’activité de copie :

Si vous utilisez PolyBase ou des paramètres avancés, vérifiez que l’option « Utiliser le type par défaut » est correctement configurée. Ce paramètre peut affecter le mappage des types et l’apparition d’erreurs.

Analyser les journaux du pipeline :

Examinez vos journaux ETL pour obtenir plus de détails sur les lignes ou les tables en échec, ce qui peut révéler certains formats de valeurs ou des déclencheurs de précision/échelle.

Tester avec des données isolées :

Essayez avec des échantillons plus petits ou supprimez temporairement les colonnes décimales pour déterminer si le problème est lié à des valeurs de données spécifiques.

Comparaison des schémas de table :

Récupérez et comparez les définitions des tables source et de destination afin de vérifier l’absence d’incompatibilités cachées.

Si le problème persiste :

Veuillez fournir :

Les définitions des colonnes décimales des tables source et cible.

Un exemple de données de ligne (anonymisées si nécessaire) qui déclenche l’erreur.

Tout schéma observé dans les données réussies et celles ayant échoué.

Les modifications récentes apportées à vos pipelines ou schémas de table.

La confirmation que les échecs se produisent systématiquement lors de plusieurs exécutions.

Références :

Azure Synapse Analytics - Erreurs ETL personnalisées

Dépannage des connecteurs Azure Data Factory

Copier l’activité dans Azure Data Factory

J’espère que cela vous aidera à résoudre le problème ! N’hésitez pas à demander de l’aide supplémentaire si nécessaire.

Vincent Labrecque 35 Points de réputation

2025-12-01T15:30:58.05+00:00

Hi, my original message was in English and got translated without my consent. I guess it's because I ended up for some reason in the French section of the community forums.

I confirm that a temporary workaround has been found last week, allowing our daily pipelines to execute again.

We ended up writing the extract queries explicitly and casting the numeric columns into varchars. Beforehand, we did not need to write select statements for our 130 tables. The copy activity would detect the data types and successfully copy the data into parquet files.

This workaround has been executed for the 7 tables that were failing. We are still at risk of a new failure if any of the 123 other tables begin to fail for some reason. Should that happen, we would need to write queries for all of them.

That would be time consuming and it would make the Synapse solution less attractive.

I will remain attentive for a durable fix. Thank you

1 réponse supplémentaire

Votre réponse

Pilladi Padma Sai Manisha 11,715 Points de réputation Personnel externe de Microsoft Corporation Modérateur

2025-11-27T05:16:56.03+00:00

Hi Vincent Labrecque,
I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.
Vincent Labrecque 35 Points de réputation

2025-12-01T15:31:50.3566667+00:00

Hi @Pilladi Padma Sai Manisha , I have replied to your last comment. Thank you
Mamadou SIDIBE 0 Points de réputation

2025-12-08T16:35:02.2733333+00:00

Bonjour,

Après échange avec une personne du support Microsoft, nous avons pu confirmer que le problème rencontré avec le composant Copy Data et le connecteur PostgreSQL provient d’un bug présent dans les versions récentes du Self-Hosted Integration Runtime (SHIR) — notamment les versions 5.60 et 5.55 — qui n’arrivent pas à lire correctement les valeurs décimales. Le bug est connu de l’équipe produit, un correctif est prévu, mais il n’y a actuellement aucune date de résolution (ETA).

De notre côté, nous avons mis en place une solution de contournement qui fonctionne :

Désinstallation de la version 5.60,

Installation de la version 5.22 (téléchargée depuis le site officiel Microsoft), → Cette version fonctionne correctement et permet d’exécuter les copies de données sans erreur.

Je confirme donc que la version 5.22 fonctionne dans notre cas comme solution temporaire. Nous restons en attente d’une version plus récente corrigée, et Microsoft nous informera dès qu’un fix sera disponible.
Vincent Labrecque 35 Points de réputation

2025-12-01T15:30:58.05+00:00

Hi, my original message was in English and got translated without my consent. I guess it's because I ended up for some reason in the French section of the community forums.

I confirm that a temporary workaround has been found last week, allowing our daily pipelines to execute again.

We ended up writing the extract queries explicitly and casting the numeric columns into varchars. Beforehand, we did not need to write select statements for our 130 tables. The copy activity would detect the data types and successfully copy the data into parquet files.

This workaround has been executed for the 7 tables that were failing. We are still at risk of a new failure if any of the 123 other tables begin to fail for some reason. Should that happen, we would need to write queries for all of them.

That would be time consuming and it would make the Synapse solution less attractive.

I will remain attentive for a durable fix. Thank you

Answer 1

LioTims 10

Hello,

Were are facing the same issue.

How can we solve it ?

{
    "errorCode": "2200",
    "message": "Une panne s'est produite côté « Source ». ErrorCode=UserErrorAzurePostgreSqlNpgsqlParseParamError,
		'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,
		Message=parse param error for type:Microsoft.Connectors.AzurePostgreSql.TypeMapping.BigDecimal.NpgsqlDecimal,
		value:System.Decimal,Source=Microsoft.Connectors.AzurePostgreSql,
		''Type=System.FormatException,
		Message=Le format de la chaîne d'entrée est incorrect.,Source=mscorlib,'",
    "failureType": "UserError",

LioTims 10 Points de réputation

2025-11-19T10:20:53.6233333+00:00

After further investigation, the problem is due to a numeric(7,2) column .
Vincent Labrecque 35 Points de réputation

2025-12-01T15:32:44.68+00:00

Hi @LioTims , please read my reply to Pilladi's comment for a suggestion for a workaround.