[Microsoft][ODBC Driver for SQL Server] Unexpected EOF encountered in BCP data-file
Article ID: 16412
Updated On:
Products
Issue/Introduction
This article covers importing of subset data from a Microsoft SQL Server database, and the common problems that cause the bulk copy (BCP tool) to fail on import with a EOF encountered.
I have created a transformation map, that only includes a single table, at these time, with only one column to transform. Then I create a subsetting clause to extract some records from the source database (MS SQL server 10.0.5500) and select the option "Build MS SQL Server Scrambled Extract", select the transformation map that I have created previously, and generate the files.
When I execute the export bat file it works fine and generates the dump files of the tables that have relationship. When I execute the import bat file, it fails to populate the records to the source database. The message from the command prompt is:
dbo.tableXXXX
Starting copy...
SQLState = S1000, NativeError = 0
Error = [Microsoft][ODBC Driver 11 for SQL Server]Unexpected EOF encountered in BCP data-file
Environment
Component:
Resolution
If you run into an issue where you see an Unexpected EOF encountered in BCP data-file, it will be one of two things.
1) When you export out with Subset, and import back into a target database, we use the internal tools from Microsoft to generate the export (bulk copy). If you are importing into a different version of Microsoft SQL server, you will get incompatibility errors, including the Unexpected EOF error.
2) Along with the same version of SQL Server, make sure the database you are subsetting from has the exact same database structure as the database you are importing to. In this example, there was a new foreign key constraint on the target database that did not exist in the source database, which made the generated subset incompatible with the target database.
To confirm your database structures are the same, you can export the DDL for both the source and target database, and perform a diff on the DDL's to confirm if the structure is the same. If you are not able to do this, you should refer to your DBA on the structure of your source and target databases are the same.
Feedback
