Our software imports data from several flat files provided by a third
party. Back in 2000, when we were working with them to determine the
proper format, we had them omit the carriage return/line feed at the
end of the last line in the file because this was causing an import
problem. That was a bug which Microsoft has since fixed, but the files
have remained that way ever since. Recently, we added a new file to
the ones we've been importing for years. This one drops the last row
on the import unless the carriage return/line feed is there. The third
party is resisting making any changes to the file format, and we are
reluctant to tamper with the flat file they send us until we know
what's going on.

The new file is identical to an old one that still imports properly,
except that the new one has additional columns at the end. I can take
a file in the old format and simply change the header to the one with
the extra columns, and it too will drop the last row when it's
imported. If I put the original header back in, then the last row is
imported.

If you look at the size of the fields being imported (as defined by the
table into which DTS puts them), the old file has a maximum line length
of 250 characters; the new file's maximum file length is considerably
longer. Given the problem DTS has exporting varchar fields that are
over 255, I'm wondering if something of the sort is going on here.

Any information to explain this would be greatly appreciated. We're
using Sql Server 2K, so I'm also wondering if there will be any
difference in how DTS behaves when we upgrade to 2005.