Hi I have found a few posts with similar errors but none really have a solution only a work around, none of which have worked. As part of a text file import to SQL Server Destination, which has been working for some time with small file sizes, failed today with the following error when a 10k row file was received (xxx for sensitivity) Executed as user: xxx. Microsoft (R) SQL Server Execute Package Utility Version 10.0.2531.0 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 15:41:53 Error: 2011-04-27 15:42:01.40 Code: 0xC0047038 Source: xxx SSIS.Pipeline Description: SSIS Error Code DTS_E_PRIMEOUTPUTFAILED. The PrimeOutput method on component "xxx" (1) returned error code 0x80040E21. 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. There may be error messages posted before this with more information about the failure. End Error DTExec: The package execution returned DTSER_FAILURE (1). Started: 15:41:53 Finished: 15:42:01 Elapsed: 8.283 seconds. The package execution failed. The step failed. I have run the package manually and produced the same error, there are no other details on the error produced. Data commits successfully with a limited number of rows (9777 of 10884) within the data flow but the control flow fails with above error. Changing maxbufferrows setting causes some differences, such as failure to import at all or reaching over 10k rows before error. This same package imports other files (not at the same time) of millions of rows and more columns without any problems. The source file does not appear corrupt, and the rows around 9777 import successfully if done alone. Have checked with a hex viewer for erroneous chars. Next step is to install SP2, but cant see any reference to fixing this (as opposed to 2005 SP which does, assume should be already fixed in 2008). Any suggestions welcome.

Somewhere in 9777 of 10884 inspect the data for quality e.g. illegal/non printing chars may be there Arthur My Blog

Thanks for the suggestion, however as I said have already tried shifting around the content. I even tried removing all rows after 7000, that caused the source in the dataflow to succeed (turn green at least) but no down stream tasks ran, and the same error was generated by control flow.

Has something changed in between then? Something is not longer the same with the destination. What are you doing with the file specifically, what is involved, I sense there is something very non-standard there. Arthur My Blog

Nothing has changed, no new release for several weeks. The data flow contains a source flat file, script component to add an MD5, conditional split to remove a footer row and SQL server detination. Also tried with OLEDB destination with various settings for commit size etc. MD5 task works fine for 32 other imports. There are many references to this error on the web even with simple imports, but never a true solution.

Do you mean it will consume other input files but not this particular one? Enable logging and run the package again in order to see where exactly it dies, you need to pinpoint the exact place.Arthur My Blog

Correct, it is only this file so far, and only when this large version has appeared with 10k rows. yet other files have over 1 million rows on a daily basis. The one IAS package imports 33 files depending on a parameter to enable/disable each dataflow, downstream activities are then the same for all files. Logging is already on, no futher or previous messages are received as suggested in the error.

Just examined logs again, cannot see any other errors. The first occurence of the error is against the name of the data flow task, it is then repeated for each parent container (sequence, loop, and package). This is with all available logging options on. It is then followed by the generic error below. SSIS Warning Code DTS_W_MAXIMUMERRORCOUNTREACHED. The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors. It seems as if the source is only providing 9777 rows rather than failing / rejecting at the destination. "Rows were provided to a data flow component as input. : : 1708 : Body : 82 : xxx Stage : 98 : SQL Server Destination Input : 9777" There are no rows output to the failure redirection when using an OLEDB desitination. In addition this happens when run on my local PC as well as the UAT server. Trying the same import in a SQL2000 DTS package works without any issues, importing all 10884 rows.

Just examined logs again, cannot see any other errors. The first occurence of the error is against the name of the data flow task, it is then repeated for each parent container (sequence, loop, and package). This is with all available logging options on. It is then followed by the generic error below. SSIS Warning Code DTS_W_MAXIMUMERRORCOUNTREACHED. The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors. It seems as if the source is only providing 9777 rows rather than failing / rejecting at the destination. "Rows were provided to a data flow component as input. : : 1708 : Body : 82 : xxx Stage : 98 : SQL Server Destination Input : 9777" There are no rows output to the failure redirection when using an OLEDB desitination. In addition this happens when run on my local PC as well as the UAT server. Trying the same import in a SQL2000 DTS package works without any issues, importing all 10884 rows. Also previewing the file in SSIS connection manager and skipping the first 9777 rows or more is successfull. I don't believe the file is corrupt.

Any further advice on this from anyone? SP2 did not fix the issue.

Just like the end of all the other posts I find on this error then!

Just like the end of all the other posts I find on this error then!

Try changing your source component from OLEDB to ADO. Can you?Arthur My Blog

Try changing your source component from OLEDB to ADO. Can you?Arthur My Blog

The source is a flat file, do you mean destination? I have already tries OLEDB and SQL Server.

Does it failing at the same source file or any other, too?Examine your data for quality using a good text editor capable of displaying hidden characters as Notepad++. Next try executing this package differently, say if you use SQL Agent run it with DTExec preferably using different credentials. Restart the machine, clean cache and the temp directory beforehand.Arthur My Blog

This is the only one we have had causing the failure, normally the file is only a few rows, but a system setting change caused a one off output of this size. I have already examined the file with V Viewer in hex mode and can see no rogue characters. I have also asked the providers to do this with no problems found. I have tried executing the same package on my machine as mentioned and still produces the same error (using my credentials).