Is there no way around the problem of preventing garbage data from screwing
up an ExportData and corresponding ImportData using a BulkCopy object? I
was using the tab as the delimiter until some errant data (an embedded tab)
in a field caused the import to fail. You can set your own delimiter, but
wouldn't it be inevitable that some errant garbage in a field will cause the
same problem?

How are you handling this?

Thanks,

Darian

"Darian Miller" <darian-remove- (AT) promaxautonews (DOT) com> wrote

I take it not too many people use the BulkCopy object? Or, is this the
wrong forum perhaps?

Darian

Do you refer to the BulkCopy object in DMO ?

Embedded delimiters is always a problem regardless of delimiter.

On way to do it would be to cleanse the text file and get rid of embedded
delimiters.
Another way would be to clean the file to another file. Your rows that are
good should contain a known amount of delimiters so when you encounter a row
with more than this amount you could write it out to a file as a bad row

--
--

Allan Mitchell MCSE,MCDBA, (Microsoft SQL Server MVP)
www.SQLDTS.com - The site for all your DTS needs.
www.konesans.com - Consultancy from the people who know


"Darian Miller" <darianmiller (AT) gospamyourself (DOT) com> wrote

Thanks for the reply!

I suppose one manual pass through the file before importing it would still
be quicker than any alternative. Thanks for pointing out the obvious.

Darian

"Allan Mitchell" <allan (AT) no-spam (DOT) sqldts.com> wrote