The rules are really simple

* NULLs and BLOBs can't be stored in external tables.
* everything is stored as fixed length values.

That's all !

E.g.
INTEGER = 4 bytes
SMALLINT = 2 bytes
TIMESTAMP = 2 integers = 8 bytes
CHAR(10) = 10 bytes
VARCHAR(10) = 2+10 = 12 bytes

Fixed length means that even single character
stored in VARCHAR(10) will still require 12 bytes
(for single byte character sets).

If you expect that external file contains CRLF or LF,
you have to create appropriate column for it
(either CHAR(1) or CHAR(2) or SMALLINT).

Your declaration
(A VarChar(10),B VarChar(2),C VarChar(6));
means that one record is 2+10 + 2+2 + 2+6 = 24 bytes, no crlf expected.

Ivan
http://www.volny.cz/iprenosil/interbase/

> Double Precisions, Integers, Small Integers, and Time stamps are all
> represented with the appropriate number of bytes. These operate as fixed
> length values. I still dont have an exact idea of how these values are
> constructed properely, left-right, right-left, signed, etc. I will try to
> find an algorithm for constructing timestamp values.
>
> Text fields can use the Char(X) specification, but would require padding
> values and be very inefficient on disk usage and external file creation.
> Interestingly enough, you can use VarChar for a field specification.
> However, it operates with unexpected results. 2 bytes must precede the
> actual field value. You would think these 2 bytes indicate how many bytes
> to use as the field data, but it does not work that way. The number
> indicated in the file specifications overrides this. So although a Varchar
> value can be used, its still operating as a fixed length field and STILL
> requires padding of values at the end. The 2 bytes are effectively useless.
> I tested this by creating a file with 3 fields. 10,2, and 6 character field
> lengths for each field per row. All field values had hex values of 000A,
> 0002, or a 0006 as the 2 bytes preceding the field value itself. The file
> specifications where (A VarChar(10),B VarChar(2),C VarChar(6));. These
> specifications worked perfectly. However, when ...(A VarChar(15),... was
> used, it would then grab B's 2 byte length values as well as B itself and
> would then screw up the rest of the file. If 0000 were used as a byte
> length value (my thoughts on how to indicate null), it actually stopped
> processing of the entire file itself as if EOF had been reached.
>
> I am now completely lost on how to properly represent a null value in an
> external file if now even possible at all. Also, a null value inside of a
> number is an interesting question since those values do not have bytes in
> front of them to represent their length and 00 00 00 00 would represent 0 as
> an integer which is still a value.
>
> If anybody has detailed knowledge on external files, their creation, and
> corresponding file specifications i would be very gratefull.