tildechris
Not all .rpt values have the 2nd row with "dashes and spaces"
I received a .rpt file today with some important data, and I tried converting it with this script and it didn't work very well at all.
Looking at the source code I think it's because my .rpt file doesn't have a 2nd row between the header row and the 'body', which your script uses to calculate the column widths.
This might be a corner case, but I just wanted to point it out.
Yes this is obviously a case I hadn't considered. Do you know where that particular file came from (versions etc.?). Would you be able to do column detection from the header row? A sample in this format would be good.
If you want to submit a patch I'll happily pull it in, otherwise it might be a while for me to fix.
I don't know where it came from unfortunately, I was just linked to me.
Turns out it just uses tabs as delimiters. Is this possible in .rpt?
So yeah, this is just a tab-delimited file. The bad news is that no, it's not a .rpt, at least as generated by SSMS (there's no real specification that I could find.).
The good news is that tab-delimited is a much more widely supported format. For instance, you could open this directly in excel and use the text-import wizard with tab as a delimiter. Tab delimited files are nice when the input data contains commas and you don't want to escape them.
So this really isn't a bug per-se, but it probably does make sense to warn the user if the input doesn't have a second line with space separated dashes. I.e. that it doesn't look like a rpt.
Yeah I don't know how widespread this is, but it's possible someone just put the wrong extension on a .tsv file.
The warning would be useful, instead of just failing. But if this is a 1/1,000,000 case it's not worth the work.