I've got a pipe delimited file. When I try to use the dts wizard it gives me
an error.
However, when I import it into excel or access it works fine.
I think... that there may be a carriage return in some of the text data, in
one of the fields. When this happens, the wizard thinks it's the end of the
row.
Why is it that excel / access works ok? I would think that they use the
same type
of import process, since it's all microsoft products.
Is there any way around this?
My only options would appear to be...
write a program that scans character by character..
Or.. get the supplier of the file to exclude those CR's out
Anyone have any ideas?

DTS and Excel import and even access import are very definitely not the same
thing. The latter two are slightly more forgiving. Would be nice sometimes
if there was a standard way to do this but remember these routines are
developed by different product teams at MS.

What is the error given?



--


Allan Mitchell
www.SQLDTS.com
www.SQLIS.com
www.Konesans.com


"Scot S" <ScotS (AT) discussions (DOT) microsoft.com> wrote

Error shows up right after trying to set it up
Could not find the selected row delimiter within the first 8 K of data
Is the select row delimiter valid?

It comes up with a blank screen if you say yes...
if you try to force it... it will say

error source TS flat file rowset provider
Row delimiter not found

"Allan Mitchell" wrote:

OK So that is slightly different to there being the row delimiter in the
file but early. I would get a HEX editor and look for the End of Row marker
in the file. The EOR marker is set by you when you setup the file. My
guess is that the marker may not be what you think it is OR it is missing.



--


Allan Mitchell
www.SQLDTS.com
www.SQLIS.com
www.Konesans.com


"Scot S" <ScotS (AT) discussions (DOT) microsoft.com> wrote