I'm trying to import a flat file into an oledb target sql server database.
here's the field that's giving me trouble:
here are the properties of that flat file connection, specifically the field:
here's the error message:
[Source - 18942979103_txt [424]] Error: Data conversion failed. The
data conversion for column "recipient-name" returned status value 4
and status text "Text was truncated or one or more characters had no
match in the target code page.".
What am I doing wrong?
Here is what fixed the problem for me. I did not have to convert to Excel. Just modified the DataType when choosing the data source to "text stream" (Figure 1). You can also check the "Edit Mappings" dialog to verify the change to the size (Figure 2).
Figure 1
Figure 2
After failing by increasing the length or even changing to data type text, I solved this by creating an XLSX file and importing. It accurately detected the data type instead of setting all columns as varchar(50). Turns out nvarchar(255) for that column would have done it too.
I solved this problem by ORDERING my source data (xls, csv, whatever) such that the longest text values on at the top of the file. Excel is great. use the LEN() function on your challenging column. Order by that length value with the longest value on top of your dataset. Save. Try the import again.
SQL Server may be able to suggest the right data type for you (even when it does not choose the right type by default) - clicking the "Suggest Types" button (shown in your screenshot above) allows you to have SQL Server scan the source and suggest a data type for the field that's throwing an error. In my case, choosing to scan 20000 rows to generate the suggestions, and using the resulting suggested data type, fixed the issue.
While an approach proposed above (#chookoos, here in this q&a convert to Excel workbook) and import resolves those kinds of issues, this solution this solution in another q&a is excellent because you can stay with your csv or tsv or txt file, and perfom the necessary fine tuning without creating a Microsoft product related solution
I've resolved it by checking the 'UNICODE'checkbox. Click on below Image link:
You need to go increase the column length while importing the data for particular column.
Choose a data source >> Advanced >> increase the column from default 50 to 200 or more.
Not really a technical solution, but SQL Server 2017 flat file import is totally revamped, and imported my large-ish file with 5 clicks, handled encoding / field length issues without any input from me
SQl Management Studio data import looks at the first few rows to determine source data specs..
shift your records around so that the longest text is at top.
None of the above worked for me. I SOLVED my problem by saving my source data (save as) Excel file as a single xls Worksheet Excel 5.0/95 and imported without column headings. Also, I created the table in advance and mapped manually instead of letting SQL create the table.
I had similar problem against 2 different databases (DB2 and SQL), finally I solved it by using CAST in the source query from DB2. I also take advantage of using a query by adapting the source column to varchar and avoiding the useless blank spaces:
CAST(RTRIM(LTRIM(COLUMN_NAME)) AS VARCHAR(60) CCSID UNICODE
FOR SBCS DATA) COLUMN_NAME
The important issue here is the CCSID conversion.
It usually because in connection manager it may be still of 50 char , hence I have resolved the problem by going to Connection Manager--> Advanced and then change to 100 or may be 1000 if its big enough
Related
I am using MS query to pull data from sql server and all is good.
Problem starts when data comes from the server I am stuck with data type general for everything, and no way to change the data type in excel.
Main issue is numbers, where in database datatype is decimal yet i can do no calculations on it in excel. Any help would be appreciated.
I am using excel to execute a stored procedure on server
This pulls the data into the following table
Even though the data in the sql server for column price is formatted as decimal it becomes a general data type after getting to excel.
Changing it to number/currency etc. does not change anything.
Also no errors appear. Simply data comes down and no matter what changes in excel I apply nothing changes it all is treated as text.
You can do these things.
Select Column
Click Data-> Text to Columns
Follow the wizard
Set the format
Use this official support ticket from Microsoft
Problem in this case was created by myself.
But I suppose it could easily happen to others who are just starting on their path with sql and excel.
Here is what happened as I established after few days of going in circles.
as there was load of trailing spaces in the data coming down from the server I have decided to tidy things up.
Without considerring implications I have stuck an RTRIM() on everything.
This caused excel to treat everything as strings as string RTRIM is a built in string function.
What made things worse is the fact that when using power query I was able to transform the data to the desired, formats.
Unfortunately MS query does not seem to be quite as clever as power query hence the issues.
I have some data which was dumped from a PostgreSQL database (allegedly, using pg_dump) which needs to get imported into SQL Server.
While the data types are ok, I am running into an issue where there seems to be a placeholder for a NULL. I see a backslash followed by an uppercase N in many fields. Below is a snippet of the data, as viewed from within Excel. Left column has a Boolean data type, and the right one has an integer as the data type
Some of these are supposed to be of the Boolean datatype, and having two characters in there is most certainly not going to fly.
Here's what I tried so far:
Import via dirty read - keeping whatever datatypes SSIS decided each field had; to no avail. There were error messages about truncation on all of the boolean fields.
Creating a table for the data based on the correct data types, though this was more fun... I needed to do the same as in the dirty read, as the source would otherwise not load properly. There was also a need to transform the data into the correct data type for insertion into the destination data source; yet, I am getting truncation issues, when it most certainly shouldn't be.
Here is a sample expression in my derived column transformation editor:
(DT_BOOL)REPLACE(observation,"\\N","")
The data type should be Boolean.
Any suggestion would be really helpful!
Thanks!
Since I was unable to circumvent the SSIS rules in order to get my data into my tables without an error, I took the quick-and-dirty approach.
The solution which worked for me was to have the source data read each column as if it were a string, and the destination table had all fields be of the datatype VARCHAR. This destination table will be used as a staging table, once in SS, I can manipulate as needed.
Thank you #cha for your input.
I am working in Windows using SQL Server 2008 R2 and VS 2008.
I haven't been able to find any other incidence of this happening via google, but I'm having an issue with SSIS not recognizing the CRLF code in my SQL query. The problem is two fold:
In notepad, the flat file does not come out in columns. It is
just one long string of text (although this resolves in notepad++).
When viewed in notepad++, the first row of data is indented by
two characters and each subsequent row is indented even further!
Basically this file will be unreadable at the other end.
Here's an example how I'm currently approaching it:
Select col1, col2, col3, char(13)+char(10) CRLF
Which produces data like this:
Col1 Col2 Col3 CRLF
xxxx xxxx xxxx
xxxx xxxx xxxx
xxxx xxxx xxxx
Other things I have tried include:
Using declare #crlf (returns the same results)
Using only char(13) or only char(10) (returns the same results)
Using Col3+char(13)+char(10) (returns results in single line)
I think I'm missing just a small piece of the puzzle here, but I can't figure out what that piece would be. Your help is much appreciated.
Throwing in some requested screenshots here:
You can see here where the extra characters are starting to sneak in.
On the Advanced tab of the Flat File Connection Manager the InputColumnWidth might not be set correctly. I'm guessting the last column containing the CRLF, it should be 2 long.
I use the exact same dev stack you list, and I don't include the CRLF in the SQL query, I only use the row delimiter in the SSIS output connection.
In the SSIS package, edit the output connection. It displays the Flat File Connection Manager. In the "Columns" tab (well, not quite a tab, but pick Columns from the list on the left side) here is a "Row Delimiter" and I specify my CRLF there.
There is also a "Header Row Delimiter" on the "General" tab, but that only applies to the header row.
Unless there is a reason you are trying to embed a line break in the middle of a query row?
EDIT: Some more troubleshooting questions ...
1) Are you writing your file to a network drive or a local drive? Try setting to a local drive in case any automatic mapping is going on.
2) What is your data source? I usually use an OLEDB source, but if you are having trouble, maybe try a flat file input source and see if it can mimic a simple input to a simple output.
3) How are you getting your file to look at it? Are you logged on to the server and using Notepad there? If not, try that to see if the problem happens when you are getting the file to look at.
4) Are there any special characters in the data that might interfere? Try a query that returns a few constants.
EDIT 2: I saw your comment, I'll switch one of mine to fixed width and get back to you shortly - did you check to see if you made the width too short and it's clipping the termination characters?
EDIT 3:
I have to go for tonight, I'll look at this more tomorrow and get back to you, and clean my messy and confusing post up. I made a package that I tried to match yours as closely as I could but I started with a copy of an existing one instead of a fresh start and it got stuck in a half-baked state. I'll make a fresh one from scratch tomorrow.
BTW, Are all of your rows the same width? If not, have you tried Ragged Right instead of Fixed Width?
EDIT 4: Adding more ...
Over the weekend I continued to play with this and noticed that you can get SSIS to add the row delimiter for you. When you first create the Flat File Destination and edit it, you get the choice to create a new flat file connection manager, and one of the options is to add a column with CRLF. Unfortunately, this has the annoying side effect of always including a heading of "Row Delimiter Column" if you include column names in the output file. You can get around it by specifying a header row instead of building it from field names, but appending the CRLF in your SQL statement is probably a lot less work than that.
.
And for anyone else continuing to play with this, using a delimited flat file but forcing the fields to fixed length in a data transform (Derived Column) or in the SQL query also worked, but was more complicated. Within the Derived Column transform I replaced my input column (Nums) with SUBSTRING(Nums + REPLICATE(" ",4),1,4) where 4 is the field width. To do the same thing in the SQL query I used CONVERT(CHAR(4), Nums) as Nums.
SSIS by default makes the datatype to be String with length 50, what if the string in a certain column is larger than 50 and also I can't use suggest types (it sucks!).
Is there a way to fix this, rather than manually increasing the sizes ie. manually editing the column lengths/datatypes in the flat file manager's advanced tab, ideally changing datatypes based on the destination (sql server) mapping columns' datatypes?
You can set datatypes in the flat file connection manager. In the advanced section.
I've heard good things about BIDS Helper, but haven't used it myself.
I haven't found a way to change default length, or to stop it from resetting when changing the connection manager. I was pleased that you can select all columns at once in the advanced editor and change them simultaneously, that's something...
The best way I could do this was write C# code that modifies the ssis package xml file and increases the string length values by looking at the lengths of the destination table (using information_schema query)
I am importing data from a text file and have hit a snag. I have a numeric field which occasionally has very large values (10 billion+) and some of these values which are being converted to NULLs.
Upon further testing I have isolated the problem as follows - the first 25 rows of data are used to determine the field size, and if none of the first 25 values are large then it throws out any value >= 2,147,483,648 (2^31) which comes after.
I'm using ADO and the following connection string:
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=FILE_ADDRESS;Extended Properties=""text;HDR=YES;FMT=Delimited""
Therefore, can anyone suggest how I can get round this problem without having to get the source data sorted descending on the large value column? Is there some way I could define the data types of the recordset prior to importing rather than let it decide for itself?
Many thanks!
You can use an INI file placed in the directory you are connecting to which describes the column types.
See here for details:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms709353(v=vs.85).aspx