SSIS-conversie tussen Unicode- en niet-Unicode-fout

Ik heb een ssis-pakket waarbij ik een OLEDB-bron gebruik die linkt naar de SQL Server 2005-tabel. Alle kolommen behalve een datumkolom zijn NVARCHAR(255). Ik gebruik een Excel-bestemming en gebruik een SQL-instructie om het blad in de Excel-werkmap te maken, de SQL bevindt zich in de Excel-verbindingsmanager (in feite een instructie voor het maken van een tabel die een blad maakt) en is afgeleid van de toewijzing van de kolommen van de DB.

Wat ik ook heb gedaan, ik krijg steeds deze unicode –> niet-unicode-conversiefout tussen mijn bron en bestemming. Geprobeerd conversie naar string [DT_STR] tussen S > D, verwijderd, SQL-tabel VARCHAR gewijzigd in NVARCHAR en nog steeds deze flippin-fout.

Omdat ik het blad in Excel maak met een SQL-instructie, zie ik geen manier om vooraf te definiëren wat de gegevenstypen van de kolommen in het Excel-blad zullen zijn. Ik kan me voorstellen dat het standaard metagegevens zijn, maar ik weet het niet.

Dus tussen mijn SQL-tabelbestemming en het maken van mijn Excel-blad met deze SSIS sql-instructie, hoe kan ik voorkomen dat deze fout optreedt?

Mijn fout is:

Fout bij gegevensstroomtaak [OLE DB-bron [1]]: kolom “Mijn kolom” kan niet worden geconverteerd tussen unicode- en niet-unicode-tekenreeksgegevenstypen.

En voor alle nvarchar-kolommen.

Waardeer alle hulp

Bedankt

Andrew


Antwoord 1, autoriteit 100%

De onderstaande stappen werkten voor mij:

1). klik met de rechtermuisknop op de brontaak.

2). klik op “Toon geavanceerde editor”.
geavanceerde bewerkingsoptie voor brontaak in ssis

3). Ga naar het tabblad “Invoer- en uitvoereigenschappen”.

4). selecteer de uitvoerkolom waarvoor u de fout krijgt.

5). Het gegevenstype is “String[DT_STR]”.

6). Wijzig dat gegevenstype in “Unicode String[DT_WSTR]”.
Het gegevenstype wijzigen in unicode-tekenreeks

7). opslaan en afsluiten.
Ik hoop dat dit helpt!


Antwoord 2, autoriteit 77%

Gegevensconversietransformaties toevoegen om tekenreekskolommen te converteren van niet-Unicode (DT_STR) naar Unicode (DT_WSTR) tekenreeksen.

Je moet dit doen voor alle stringkolommen…


Antwoord 3, autoriteit 24%

Het ontbrekende stuk hier is het Data Conversion-object. Het moet tussen het OLE DB-bron- en bestemmingsobject staan.


Antwoord 4, autoriteit 22%

  1. Voeg eerst een gegevensconversieblok toe aan uw gegevensstroomdiagram.

  2. Open het gegevensconversieblok en vink de kolom aan waarvoor de fout wordt weergegeven. Wijzig hieronder het gegevenstype in unicode string (DT_WSTR) of welk gegevenstype dan ook wordt verwacht en sla op.

  3. Ga naar het bestemmingsblok. Ga naar mapping erin en wijs het nieuw gemaakte element toe aan het bijbehorende adres en sla op.

  4. Klik met de rechtermuisknop op uw project in de eigenschappen van solution explorer.select. Selecteer configuratie-eigenschappen en selecteer daarin foutopsporing. Stel hierin de Run64BitRunTime-optie in op false (aangezien Excel de 64-bits toepassing niet goed aankan).


Antwoord 5, autoriteit 11%

In plaats van een eerder voorgestelde Gegevensconversietoe te voegen, kunt u de nvarchar-kolom casten naar een varchar-kolom. Dit voorkomt dat u een onnodige stap maakt en heeft een hogere prestatie dan het alternatief.

Vervang in de selectie van uw SQL-statement datedoor CAST(date AS varchar([size])). Om de een of andere reden verandert dit het type uitvoergegevens nog niet. Ga als volgt te werk om dit te doen:

  1. Klik met de rechtermuisknop op de stap OLE DB Sourceen open de geavanceerde editor.
  2. Ga naar invoer- en uitvoereigenschappen
  3. Uitvoerkolommen selecteren
  4. Selecteer uw kolom
  5. Onder Eigenschappen van gegevenstype wijzigt u Gegevenstype in tekenreeks [DT_STR]
  6. Wijzig de lengte in de lengte die u heeft opgegeven in uw CAST-instructie

Hierna worden uw brongegevens uitgevoerd als een varchar en zal uw fout verdwijnen.

Bron


Antwoord 6, autoriteit 4%

Ik ondervond deze toestand toen ik Oracle versie 12 client 32 bit client had geïnstalleerd die was verbonden met een Oracle 12 Server die op Windows draaide.
Hoewel zowel Oracle-source als SqlServer-bestemming GEEN Unicode zijn, kreeg ik steeds deze melding, alsof de orakelkolommen Unicode waren.
Ik heb het probleem opgelost door een dataconversiebox in te voegen, en
het selecteren van type DT-STR (niet unicode) voor varchar2-velden en DT-WSTR (unicode) voor numerieke velden, dan heb ik de ‘COPY OF’ uit de naam van het uitvoerveld laten vallen.
Merk op dat ik steeds de foutmelding kreeg omdat ik de bronboxpijl had verbonden met de conversiebox VOORDAT ik de conversietypes instelde. Dus ik moest van bronbox wisselen en dit maakte alle fouten in de bestemmingsbox schoon.


Antwoord 7, autoriteit 4%

Niemand lijkt dit te vermelden, maar het converteren van varchar naar nvarchar in de bronquery lost het probleem ook op.


Antwoord 8, autoriteit 3%

In het bovenstaande voorbeeld verloor ik steeds de waarden, ik denk dat door het uitstellen van de validatie de nieuwe gegevenstypen kunnen worden opgeslagen als onderdeel van de metagegevens.

Stel in Verbindingsbeheer voor ‘Excel Verbindingsbeheer’ de Vertragingsvalidatie in op False vanuit de Eigenschappen.

Vervolgens stelt u in de gegevensstroom Bestemmingstaak voor Excel de ValidationExternalMetaData in op False, opnieuw vanuit de eigenschappen.

Hierdoor kunt u nu met de rechtermuisknop op de Excel-bestemmingstaak klikken en naar Geavanceerde editor voor Excel-bestemming gaan –> tabblad uiterst rechts – Eigenschappen voor invoer en uitvoer. In de map Externe kolommen kunt u nu de waarden voor gegevenstypen en lengte van de problematische kolommen wijzigen en dit kan nu worden opgeslagen.

Veel succes!


Antwoord 9, autoriteit 3%

Ik heb hetzelfde probleem gehad en heb alles geprobeerd wat hier is geschreven, maar het gaf me nog steeds dezelfde fout.
Bleek de NULL-waarde te zijn in de kolom die ik probeerde te converteren.

Het verwijderen van de NULL-waarde loste mijn probleem op.

Gegroet,
Ahmed


Antwoord 10

Maak bij het maken van een tabel in SQL Server uw tabelkolommen NVARCHARin plaats van VARCHAR.


Antwoord 11

Ik denk dat mensen dit missen. In mijn geval had ik kolommen van 100 tekens om te converteren tussen Oracle en MS Sql. Al deze dingen over gegevensconversie en geavanceerde editor zijn ongelooflijk vervelend als je kolommen van 100 tekens hebt. Plus dat SSIS SSIS is, zal het soms al je 100 geavanceerde editorwijzigingen resetten, zelfs als je VALIDATEEXTERNALMETADATA instelt op false, ongelooflijk irritant. Ik zou het niet erg vinden om de gegevensconversie uit te voeren als het enige waarde had, maar 20 jaar geleden gebruikten ETL-tools om orakelkarakters naar ms sql-tekens te brengen zonder poespas. Wat Bakalolo en Zafer zeggen is het antwoord als je veel karakterkolommen hebt en je kunt leven met nvarchar, declareer gewoon al je kolommen nvarchar in ms sql. Ik heb ook ontdekt dat de nieuwe Oracle Source (2021) niet klaagt over een unicode-conversie naar varchar in ms sql.

Other episodes