SSIS moving Dirty/Failed Rows to File or Table - ssis

I have an SSIS package that gets data from a SQL SERVER 2008 TABLE (table A)on one server to a SQL SERVER 2008 table(table B) on another server and then convert the data and move it to another table.
I'm using a data flow task to do the above.
The datatype of 2 columns, column 1 and column 2 in both the tables is varchar(60) and varchar(50) respectively.
I need to import the data from table B which is the staging table to a final table(table C).The data type of the above 2 columns is of type int in table C. I'm converting the above 2 columns to int data type when I import the data, for which I have a dataflow task, in which the OLEDB source
has the following query:
SELECT CAST(COLUMN1 AS INT), COLUMN2 AS INT)
FROM TABLE B
Hi
I have 2 SQL tables i.e OLEDB Data sources , one which has the correct rows(that have been successfully converted to int) thru green arrow, and the other that has erroneous rows(that throw an error) thru red arrow.(It is configured to redirect row only on conversion error, it has "failed component" option when a truncation error occurs)the oledb destination tables has the same structure as Source Table.
When I run the data flow task that imports data from Source Table to Destination Table, I get an error
"invalid character value for cast specification" or the data conversion error.
I do not want it throw an error, but rather redirect the erroneous rows to the error table with the same structure as the destination table, with same structure has source table with error no and column name
Would it be a good idea to use a data conversion task and redirect the errors rows, by configuring an error output on conversion as well as truncation or just on conversion or cast the value and redirect rows only when conversion error occurs?

As the CAST error occurs within the SQL engine you cannot redirect those rows using SSIS. I would use a data conversion task and redirect the error rows.
FWIW I'm not a fan of "error tables" - in my experience no-one every looks at them. I prefer the "aggressive load" style (even the name is cool) where you force all rows in and make the analysts explain the discrepancies. They soon get around to fixing the serious issues as they distort their results. There will always be a low level of trivial errors that its best not to get hung up on, with life being so short and all...

Related

Error code DFExecutorUserError / Problem with loading a CSV file from Blob storage to an Azure SQL Database

I am having trouble with importing a CSV file to Azure SQl Database, it dives me the following error:
Error code: DFExecutorUserError;
Failure type: User configuration issue;
Details: Job failed due to reason: The given value of type NVARCHAR(360) from the data source cannot be converted to type nvarchar(50) of the specified target column.
Source: Pipeline pipeline1;
Data flow dataflow1;
Monitor: Data flow activity Data flow1
The Dataflow consists of a source, derived column (where I convert the datatypes of a few columns from string to int and date) and a sink.
One of the Columns (Message) has a lot text on every row (most of all e-mails from customers) and on that column I have set varchar max in the Database.
Thanks in advance for the replies.
In my System I tried to reproduce the similar issue and also got the same error as you.
The main cause of error is when we move data from blob to SQL and we have already created table with small column size can trigger this issue. as we cannot enter value in column beyond its size.
To resolve this either at time of creation of table if you don't know the size of column then set it to max or ad the precopy script to sql alter column size to max and then run your pipeline.
ALTER TABLE table_name ALTER COLUMN column_name varchar(max)
Pipeline executed successfully.

SSIS: cannot convert between unicode and non-unicode string data types

I am working in SQL Server 2008 and BIDS (SSIS). I have a simple data flow task in which I'm importing a flat file into an OLE DB destination. On the OLE DB destination, I'm getting an error message, stating "cannot convert between unicode and non-unicode string data types".
Now, I know one solution method is to put a data conversion in between the flat file and the OLE DB destination. However, my concern is why this is even happening in the first place. In the connection manager for the given flat file, all columns are string (DT_STR) data types, and the Unicode option is unchecked. Similarly, all columns in the destination table (upon the inspection of the metadata in SSMS) are varchar data types. So, there is no nvarchar-to-varchar mapping going on at all.
Why is SSIS thinking that I have a unicode-to-nonunicode mapping happening? And, is there an easier way to resolve this than inserting a data conversion step for the columns that have this problem?
[Since I don't seem to be allowed to comment on the question, I'm having to put my question here.]
Have you checked the table you're trying to insert the data into to see if the columns in the table are varchar or nvarchar? The SSIS metadata could be out of sync with the database table.

SQL Server: How to override Error 0xc02020a1: Data Flow Task 1: Data conversion failed

I'm using SQL Server Import Wizard to import a 260GB flat text file into a table. I have about 25 fields/columns per row and endless rows. The large text file has vertical bars as a column delimiter and {CR}{LF} as a row delimiter.
My issue is this: some of the rows of data are not clean and missing a column delimiter or have an extra column delimiter. Thus, data is getting pushed into the wrong fields. This is problematic because each column has a very unique data type, thus creating the SQL Server data conversion failed error.
I don't mind incorrect data being pushed into the wrong fields - it seems to be happening for .01% of transactions and isn't a big issue. So I would like to override this issue and continue loading the data. Right now the problem is SQL Server Import wizard stops all together when it hits this error, meaning I have to cleanse the data and to reload each time (very painful for such a large text file).
Any help/advice/suggestions on strategy here?
Thanks
Using the wizard,In the review data type mapping set the on error (global) to ignore

The value violated the integrity constraints for the column

I am trying to import the data from Excel file into SQL Server database. I am unable to do so because I am getting following errors in the log file. Please help. The log erros are as as follows:-
[OLE DB Destination [42]] Error: An OLE DB error has occurred. Error code: 0x80040E21. An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80040E21 Description: "Multiple-step OLE DB operation generated errors. Check each OLE DB status value, if available. No work was done.".
[OLE DB Destination [42]] Error: There was an error with input column "Copy of F2" (5164) on input "OLE DB Destination Input" (55). The column status returned was: "The value violated the integrity constraints for the column.".
[OLE DB Destination [42]] Error: The "input "OLE DB Destination Input" (55)" failed because error code 0xC020907D occurred, and the error row disposition on "input "OLE DB Destination Input" (55)" specifies failure on error. An error occurred on the specified object of the specified component.
[DTS.Pipeline] Error: The ProcessInput method on component "OLE DB Destination" (42) failed with error code 0xC0209029. The identified component returned an error from the ProcessInput method. The error is specific to the component, but the error is fatal and will cause the Data Flow task to stop running.
[DTS.Pipeline] Error: Thread "WorkThread0" has exited with error code 0xC0209029.
[Excel Source [174]] Error: The attempt to add a row to the Data Flow task buffer failed with error code 0xC0047020.
[DTS.Pipeline] Error: The PrimeOutput method on component "Excel Source" (174) returned error code 0xC02020C4. The component returned a failure code when the pipeline engine called PrimeOutput(). The meaning of the failure code is defined by the component, but the error is fatal and the pipeline stopped executing.
It usually happens when Allow Nulls option is unchecked.
Solution:
Look at the name of the column for this error/warning.
Go to SSMS and find the table
Allow Null for that Column
Save the table
Rerun the SSIS
Try these steps. It worked for me.
See this link
Delete empty rows from Excel after your last row of data!
Some times empty rows in Excel are still considered as data, therefore trying to import them in a table with one or more non nullable columns violates the constrains of the column.
Solution: select all of the empty rows on your sheet, even those after your last row of data, and click delete rows.
Obviously, if some of your data really does vioalte any of your table's constraints, then just fix your data to match the rules of your database..
As a slight alternative to #FazianMubasher's answer, instead of allowing NULL for the specified column (which may for many reasons not be possible), you could also add a Conditional Split Task to branch NULL values to an error file, or just to ignore them:
It's as the error message says "The value violated the integrity constraints for the column" for column "Copy of F2"
Make it so it doesn't violate the value in the target table. What the allowable values are, data types, etc are not provided in your question so we cannot be more specific in answering.
To address the downvote, No, really it's as it says: you are putting something into a column that is not allowed. It could be Faizan points out, that you're putting a NULL into a NOT NULLable column, but it could be a whole host of other things and as the original poster never provided any update, we're left to guess. Was there a foreign key constraint that the insert violated? Maybe there's a check constraint that got blown? Maybe the source column in Excel has a valid date value for Excel that is not valid for the target column's date/time data type.
Thus, baring concrete information, the best possible answer is "don't do the thing that breaks it" In this case, something about "Copy of F2" is bad for the target column. Give us table definitions, supplied values, etc, then you can specific answers.
Telling people to make a NOT NULLable column into a NULLable one might be the right answer. It might also be the most horrific answer known to mankind. If an existing process expects there to always be a value in column "Copy of F2" changing the constraint to NULL can wreak havoc on existing queries. For example
SELECT * FROM ArbitraryTable AS T WHERE T.[Copy of F2] = '';
Currently, that query retrieves everything that was freshly imported because Copy of F2 is a poorly named status indicator. That data needs to get fed into the next system so... bills can get paid. As soon as you make it such that unprocessed rows can have a NULL value, the above query no longer satisfies that. Bills don't get paid, collections repos your building and now you're out of a job, all because you didn't do impact analysis, etc, etc.
I've found that this can happen due to a number of various reasons.
In my case when I scroll to the end of the SQL import "Report", under the "Post-execute (Success)" heading it will tell me how many rows were copied and it's usually the next row in sheet which has the issue. Also you can tell which column by the import messages (in your case it was "Copy of F2") so you can generally find out which was the offending cell in Excel.
I've seen this happen for very silly reasons such as the date format in Excel being different than previous rows. For example cell A2 being "05/02/2017" while A3 being "5/2/2017" or even "05-02-2017". It seems the import wants things to be perfectly consistent.
It even happens if the Excel formats are different so if B2 is "512" but an Excel "Number" format and B3 is "512" but an Excel "Text" format then the Cell will cause an error.
I've also had situations where I literally had to delete all the "empty" rows below my data rows in the Excel sheet. Sometimes they appear empty but Excel considers them having "blank" data or something like that so the import tries to import them as well. This usually happens if you've had previous data in your Excel sheet which you've cleared but haven't properly deleted the rows.
And then there's the obvious reasons of trying to import text value into an integer column or insert a NULL into a NOT NULL column as mentioned by the others.
Teradata table or view stores NULL as "?" and SQL considers it as a character or string. This is the main reason for the error "The value violated the integrity constraints for the column." when data is ported from Teradata source to SQL destination.
Solution 1: Allow the destination table to hold NULL
Solution 2: Convert the '?' character to be stored as some value in the destination table.
You can replace the values "null" from the original file & field/column.
the point can be if you are not using valid login for linked server. Problem is on destination server side.
There are few steps to try:
Align db user and login on destination server:
alter user [DBUSER_of_linkedserverlogin] with login = [linkedserverlogin]
recreate login on destination server used by linked server.
Backup table and recreate it.
2nd resolved my issue with "The value violated the integrity constraints for the column.".

SSIS DataFlow from Access to MSSQL

I have a simple DataFlow with two objects the source which is a mdb file and the destination which is an MSSQL database.
The idea is to migrate the data from one to another.
The problem is that the data is extracted from an Access query, and one column has ~1000 characters, and in SSIS in advanced properties the external column has the default 255 length so when i execute the task it tries to truncate it. To disable the throw error on truncate is not an option, and modifying the Length of the external column cannot be done, it throws and error regarding the metadata.
First of all can anyone explain WHY?
Second of all i need a resolution and i need it fast because it's kinda driving me crazy.
This kind of problem occours, because the ssis task "guesses" the length of the column by inspecting the first 100(afaik) rows. So if all rows from 1 to 100 have a length of 10 and the row 101 has the legnth of 11, the task will fail, because the length was "guessed" to 10.
Modifying throws an error, because you have validateExternalMetadata set to true. To solve this problem, go to advanced options of your import task (access) and set the value to false.
This means, the task will accept modified values you entered without checking it.
Did you try to SSIS Import and Export Wizard to import the data, from within the BI development environment? That is the easiest way with MsAccess as this not only imports the data but also saves the package. If you get an error during the import ( using the wizard), please post it, as this helps in further investigation. Also, as #stb suggested, try having the first record over 1000 characters.
Access supports queries which are the equivalent to views in MSSQL.
The column size is defined not by looking at a few results but by the default column length of the column data type.
I created another table with the desired data types and before the data flow i've put in the package 2 sql scripts: one to delete all the data in the table and one to execute the query against the table, as to treat it as a temporary table.
Then the actual data flow is executed against this pseudo-temporary table.
This solved my problem.