Agreed, but then what is the point of having statements like RECORD 2;? Why have functionality inbuilt that doesn't behave in line with the function?
Whilst I know it does not mean this, this would suggest that loading a flat text file with column headers simply will not work, because the headers will not match up with the (CHAR(x)) settings of the DEFINE statement. The workaround of not have the column headers is a reasonable one, but will not work for everyone/every application.
It'd be interesting to see this functionality built into Fastload properly and behave consistently.
The RECORD command was a part of the FastLoad utility many years prior to the addition of VARTEXT support.
(Believe it or not, VARTEXT was not very popular many years ago, all data was in binary format.)
In fact, the RECORD command was originally put into place so that users could test out a small subset of their data prior to running long jobs (they wanted to make sure their binary data would load correctly).
When VARTEXT format was added, the RECORD statement processing was not modified to take into account header rows for delimited data. The original design was to support files that looked like /etc/passwd (not that file, but files with that type of formatting).
We have had very few (hard to believe sometimes) requests of your nature, and at this point in time there are no plans on changing the behavior (technically, our SA/legacy utilities are "capped". meaning no new functionality goes into them except for supporting new DBS features). All new features and functionality go into TPT.
Incidentally, TPT will support the processing you are looking for.
Many thanks for that. Great background to the history of Fastload and loading.
We've not really started using Teradata Parallel Transporter, but I think I may suggest we do so in future.
The sooner you begin to use TPT the better.
The legacy utilities will never go away, but there are many more features in TPT and TPT is the loading tool going forward.