defaut size when reversing : Portal

S

Stéphane ROLLAND

started a topic almost 2 years ago

I have a PostgreSQl database with no longer defined

and when I reversed it in XDI , the defaut size is 2147483647

And when i make a mapping with this table i have an error.

How can i fix it by changing defaut size ?

champ.jpg

(73 KB)

Best Answer

A

Audric FREY said about 20 hours ago

Bonjour,

Cette erreur SQL Server survient lors de la création de la table de load (Creation of load table) : la taille demandée pour la colonne L20_cpspe dépasse 2 147 483 647 (soit INT.MAX, typiquement issu d'un mapping VARCHAR(MAX)/type illimité), alors que SQL Server limite un VARCHAR/NVARCHAR classique à 8000 caractères.

Correction : dans la metadata source (ou dans la reverse-engineering) de la colonne L20_cpspe, réduire explicitement la taille déclarée à une valeur ≤ 8000 (si la donnée réelle le permet), ou bien passer ce champ en type VARCHAR(MAX)/NVARCHAR(MAX) côté définition de la table cible SQL Server (au lieu d'une taille numérique fixe énorme), ce qui est le type approprié pour du texte volumineux illimité sur cette technologie.

Cordialement,

S

Stéphanie FOURRIER

said almost 2 years ago

Hello Stéphane,

can you please copy/paste the detailed stack trace of your error ? It will help investigate, find the root cause, and eventually point to the right solution to your problem.

Thanks !

Stéphanie.

S

Stéphane ROLLAND

said almost 2 years ago

Bonjour,

Ci dessous l'erreur que je rencontre.

A

Audric FREY

said about 20 hours ago

Answer

Bonjour,

Cette erreur SQL Server survient lors de la création de la table de load (Creation of load table) : la taille demandée pour la colonne L20_cpspe dépasse 2 147 483 647 (soit INT.MAX, typiquement issu d'un mapping VARCHAR(MAX)/type illimité), alors que SQL Server limite un VARCHAR/NVARCHAR classique à 8000 caractères.

Correction : dans la metadata source (ou dans la reverse-engineering) de la colonne L20_cpspe, réduire explicitement la taille déclarée à une valeur ≤ 8000 (si la donnée réelle le permet), ou bien passer ce champ en type VARCHAR(MAX)/NVARCHAR(MAX) côté définition de la table cible SQL Server (au lieu d'une taille numérique fixe énorme), ce qui est le type approprié pour du texte volumineux illimité sur cette technologie.

Cordialement,