When I use the export wizzard to create a delimited text file with no column headers it leaves a blank row at the top. I want just the data with no headers or blank line at the top. Is there any way to get rid of the blank row?
- Greg
I’m afraid that this is a bug and no workaround available unless you edit the exported file afterwards. CR110087 is created to address it.
Sorry for the inconvenience.
You can use run program to use the More command to remove that 1st blank row. The syntax is: More +1 Path\FileNameWithBlankRow > Path\FileNameWithoutBlankRow
You can tell run program to execute More and pass the arguments +1 etc. on the arguments line or call a batch file (which I prefer) and pass the file names as variables. The batch job then executes the More command for any files names passed to it.
While that’s certainly a work around - and a creative one at that - it seems silly that this is even an issue.
My guess is that the problem originates from using the Excel components to generate the CSV file, instead of simply exporting the data as text, and slapping a .csv extension on it. I say that, because at one point the Export Wizard was defaulting to exporting .csv in binary encoding, of all things - something that cannot happen if it was properly exporting as text.
I’ve seen this from a number of vendors who don’t seem to get that a true csv file is nothing more than text that’s separated by commas (or really any other delimiter - | is far more useful in most cases, especially if you have free-form text fields that may have commas as part of their content) with a .csv extension instead of a .txt
N.B., It is not an Excel issue. When using the export wizzard or select to file you have the option not to include headers. When you use this option (no matter what delimiter you use) it leaves a blank row at the top where the headers would have been. It is a bug and there is a change request (CR110087) to address it. The More command is just a workaround until it is fixed (but it is real slow for very large files as I have been finding out).
Since this has been going on for well over a year, are we any closer to getting the CR110087 in a new version or has it already been corrected? I am on version 6.0.0.323.
My coworkers and I looked into Change Request 110087. It has been successfully repaired and should be present in the most recent release of Toad Data Point.
Irogers, you mentioned that you were on version 6.0.0.323, which is a Toad for SQL Server version number. I can confidently say this was resolved in the release of 6.1.
Software Associate Developer I,
-Joshua Liong