SQL Snapshot Replication Fails with BCP EOF / NULL Errors (Works in Transactional Replication)

We've had this same issue with nightly snapshots since 2026-03-30 when our first snapshot replication failed. All of the errors have been consistently unexpected EOF/duplicate PK/field length, suggesting that either a field or line terminator is not being respected. After troubleshooting for about a week, we moved to backup/restore for that situation. In the last month we have had 9 other occurrences of this during transactional replication setups, all coming from different environments, publishers, subscribers, and databases. Our publishers are all fully patched SQL 2019 and the subscribers are varied since they are under the control of other parties, but are SQL Server 2017-2022 as well as Azure SQL Database. The only solution we've found is to move to character encoding, but that seems to be causing massive slowdowns in the transfers. I will try the WHERE 1=1 filter on my next snapshot using native encoding, which I anticipate creating in the next 1-2 days, to see if it is successful and if things speed up. This has been a massive headache for our team as we manage around 100 transactional replication setups with pull subscriptions, most with 5 or more publications. These regularly have to be taken down and set back up as part of normal operations, so we hope to find a more performant solution and thank the community here for this additional suggestion as we have been searching for something specific in our environment to explain the sudden change.

As a follow-up to my comment, we've tried the 1=1 filter on all articles in 4 different subscriptions across two environments and it worked for 3 of those in one environment but not for 1 in the other environment. In the failing environment we still received the missing field separator or line terminator error so we went back to character encoding to successfully transfer the initial snapshot for transactional replication. Unfortunately we cannot just upgrade SQL Server for support purposes, so we'll continue to hunt additional workarounds or a common root cause and lower our threshold for backup initialization candidates.

It's interesting that you can give a specific date for when this issue started to appear. What may have happened on that day?

1. A update to SQL Server? Unlikely, since you are on SQL 2019 which is out of mainstream support.
2. A Windows patch that causes the snapshot files to be garbled?
3. A change in your data which triggers a bug in replication?

The error message seems somewhat inaccurate to me. For native-format bulk copy I would not expect any line or field terminators, but I don't know how their format files look like.

As I said earlier, to investigate this, I would need a repro that demonstrates the issue.

While you may not be able to upgrade in production, I think that you would still be served by trying to repro this in a test environment on SQL 2019 and then upgrade that environment to SQL 2025. If the issue persists in SQL 2025, there is all reason to open a support case with Microsoft.

Hello Erland,

To my knowledge, there were no changes made by our organization on that date, which has made this difficult to track down. We had last patched over a week prior during our monthly maintenance window. We were only able to pinpoint to the date because this particular setup ingested it's snapshot daily and it worked the night before but never worked again afterwards, after multiple attempts. We removed the first table that threw an error and it moved to another table. I think that by the time we got to 7 tables we stopped trying to remove them because it seemed evident that this was likely not a data issue if it is happening in 7 unrelated tables. The following weekend we had two other environments that were seeing the same issues, which does indicate a sweeping change of some sort. After a month of looking at it, we were questioning whether it may be due to a platform change by our cloud provider affecting the network transfer or the storage target.

I hadn't considered trying to get a 2025 instance set up just to reproduce and potentially getting support, but will see if we can pursue that avenue regardless of whether our application is 2025 ready or not. No expectations of investigation on your part, just relieved that we're not the only ones seeing this and wanted to add our experience for anyone in the community that may stumble upon this.

Had it been a single table, I would lean towards that there is some data issue that took the table over the brink. But seven? Well, if the same funny data has crept into all tables, but I believe you when you say that the tables are unrelated. I'm afraid that I am out of ideas for now.