Ik probeer een groot CSV-bestand (meerdere optredens) in SQL Serverin te voegen, maar zodra ik de Import Wizarddoorloop en uiteindelijk probeer het bestand te importeren Ik krijg het volgende foutenrapport:
- Uitvoeren (fout)
Berichten
Fout 0xc02020a1: Gegevensstroom Taak 1: Gegevensconversie mislukt. De gegevens
conversie voor kolom “”Titel”” geretourneerde statuswaarde 4 en status
tekst “Tekst is afgekapt of een of meer tekens kwamen niet overeen in de
doelcodepagina.”.
(SQL Server Import and Export Wizard)
Fout 0xc020902a: Gegevensstroomtaak 1: De “Bron –
Train_csv.Outputs[Flat File Source Output].Columns[“Title”]” mislukt
omdat truncatie is opgetreden en de dispositie van de truncatierij is ingeschakeld
“Bron – Train_csv.Outputs[Flat File Source Output].Columns[“Title”]”
specificeert een fout bij het inkorten. Er is een afbreekfout opgetreden op de
gespecificeerd object van de gespecificeerde component.
(SQL Server Import and Export Wizard)
Fout 0xc0202092: Gegevensstroom Taak 1: Er is een fout opgetreden tijdens de verwerking
bestand “C:\Train.csv” op gegevensrij 2.
(SQL Server Import and Export Wizard)
Fout 0xc0047038: Gegevensstroomtaak 1: SSIS-foutcode
DTS_E_PRIMEOUTPUTFAILED. De PrimeOutput-methode op Source – Train_csv
geretourneerde foutcode 0xC0202092. Het onderdeel heeft een foutcode geretourneerd
wanneer de pijplijn-engine PrimeOutput() heeft genoemd. De betekenis van de
foutcode wordt gedefinieerd door het onderdeel, maar de fout is fataal en
de pijplijn is gestopt met uitvoeren. Er kunnen foutmeldingen zijn geplaatst
hiervoor met meer informatie over de storing.
(SQL Server Import and Export Wizard)
Ik heb de tabel gemaakt om het bestand als eerste in te voegen, en ik heb elke kolom ingesteld om varchar(MAX) te bevatten, dus ik begrijp niet hoe ik dit probleem met het afkappen nog steeds kan hebben. Wat doe ik verkeerd?
Antwoord 1, autoriteit 100%
In de wizard Importeren en exporteren van SQL Server kunt u de brongegevenstypen aanpassen op het tabblad Advanced(deze worden de gegevenstypen van de uitvoer als u een nieuwe tabel maakt, maar worden verder alleen gebruikt voor de brongegevens).
De gegevenstypen zijn irritant anders dan die in MS SQL, in plaats van VARCHAR(255)is het DT_STRen kan de uitvoerkolombreedte worden ingesteld op 255. Voor VARCHAR(MAX)is dit DT_TEXT.
Dus, op de Gegevensbron-selectie, op het tabblad Advanced, wijzigt u het gegevenstype van eventuele overtredende kolommen van DT_STRin DT_TEXT( U kunt meerdere kolommen selecteren en ze allemaal tegelijk wijzigen).
Antwoord 2
Dit antwoord is misschien niet overal van toepassing, maar het loste het optreden van deze fout op die ik tegenkwam bij het importeren van een klein tekstbestand. De provider van platte bestanden importeerde op basis van vaste tekstkolommen van 50 tekens in de bron, wat niet klopte. Het probleem werd niet beïnvloed door het opnieuw toewijzen van de bestemmingskolommen.
Om het probleem op te lossen, verschijnt in de “Kies een gegevensbron” voor de flat-file provider, na het selecteren van het bestand, een “Suggestie typen..”-knop onder de invoerkolomlijst. Na het indrukken van deze knop, zelfs als er geen wijzigingen waren aangebracht in het bijbehorende dialoogvenster, heeft de Flat File-provider het bron-.csv-bestand opnieuw opgevraagd en vervolgens correctde lengte van de velden in het bronbestand bepaald.
Zodra dit was gebeurd, ging het importeren verder zonder verdere problemen.
Antwoord 3
Ik denk dat het een bug is, pas de tijdelijke oplossing toe en probeer het opnieuw: http://support.microsoft .com/kb/281517.
Ga ook naar het tabblad Geavanceerd en bevestig of de lengte van de doelkolommen Varchar(max) is.
Antwoord 4
De geavanceerde editor heeft mijn probleem niet opgelost, in plaats daarvan moest ik het dtsx-bestand bewerken via Kladblok (of uw favoriete tekst/xml-editor) en handmatig waarden in attributen vervangen door
length="0"dataType="nText"(ik gebruik unicode)
Maak altijd een back-up van het dtsx-bestand voordat je het gaat bewerken in tekst/xml-modus.
SQL Server 2008 R2 draaien
Antwoord 5
Ga naar het tabblad Geavanceerd—-> gegevenstype van kolom —> Wijzig hier het gegevenstype van DT_STR in DT_TEXT en kolombreedte 255. Nu kunt u controleren of het perfect werkt.
Antwoord 6
Probleem:
De Jet OLE DB-provider leest een registersleutel om te bepalen hoeveel rijen moeten worden gelezen om het type bronkolom te raden.
Standaard is de waarde voor deze sleutel 8. Daarom scant de provider de eerste 8 rijen van de brongegevens om de gegevenstypen voor de kolommen te bepalen. Als een veld op tekst lijkt en de lengte van de gegevens meer dan 255 tekens is, wordt de kolom getypt als een memoveld. Dus als er geen gegevens zijn met een lengte van meer dan 255 tekens in de eerste 8 rijen van de bron, kan Jet de aard van het gegevenstype niet nauwkeurig bepalen.
Aangezien de lengte van de eerste 8 rijen met gegevens in het geëxporteerde blad minder dan 255 is, wordt de bronlengte als VARCHAR(255) beschouwd en kan het geen gegevens uit de kolom met meer lengte lezen.
Oplossen:
De oplossing is om de commentaarkolom in aflopende volgorde te sorteren.
Vanaf 2012 kunnen we de waarden bijwerken op het tabblad Geavanceerd in de wizard Importeren.