It is because in order to generate the fixed-width output, we need to find out how wide the column should be. When you export a grid, all data is already in memory so it is easy to find the widest cell. When you export a table, we would have to make one pass through all rows to find the cell widths and then a second pass to generate the output. It is doable but with a performance price.
We have a ticket open for this and I will add your vote.
about 5 years ago
[This reply is migrated from our old forums. The original author name has been removed]
Re: Fixed-width text file with @export
I see. I had assumed that you would use the result set metadata to determine CHAR/VARCHAR column lengths and the values set in the "Data Format" parameters (eg. NumberFormat, DateFormat, TimeStampFormat, etc.) for non-text columns. Your method would result in non-deterministic column lengths (since the column lengths would be based on the contents of each column rather than the column definitions) whereas I almost always want deterministic column lengths in order to satisfy a particular file format spec.
For now, there are a couple of ways to work around this when I'm working with SQL*Server. I can aggregate all my data in a work table where all columns are of type CHAR, or I can cast all my output columns to CHAR in my SELECT statement. In both cases I just concatenate all of my output columns into one big column and export as CSV.