Joshua Olson wrote: > What error is it throwing? If there's no error, what is the problem you are > having? No error, it exports correctly. However, it's just proving to be a pain for the 3rd party to import it, as they are looking for the CR\LF at the end of the line. The line breaks within the data are causing the file to not import properly on their end. See screen shot: http://i8.tinypic.com/86pgv1v.jpg Anthony Baratta wrote: > That might not be what you think it is. I'm not sure how you are > exporting to a flat file, but if you have the option (or write a quicky > script in the language of your choice) use a function like URL Encode > that will replace those "invisible" characters with their %## equivalents. > > Then you can track down what the exact characters are and hack them out > appropriately. I'm using a DTS package to export and automate, which calls my stored procedure. This isn't going to be run web-based at all. I'd really like to avoid going through all that trouble if it's something simple as the replace. >> Using like will force a full table scan, so you don't really need to use >> it in this context. You end up making two passes on the data, albeit the >> second pass is only on the sub-set of data you want. I'm not too concerned with performance, but thanks for the tips. The table is only 4000 rows and this will only be run once a week on a sunday.