Re: AW: Handling null-capable fields with program-described file-- reading externally described using program defined layout

IMO the CSV format implies that the data must be 'text' rather than binary. Given a typical database file [implemented with internal storage representations for a DBMS], its data could not be transported directly using FTP because text and binary are intermixed; i.e. a choice exists for text *xor* binary mode. So ignoring the line break or delimiter concerns, a true binary stream embedded in a text CSV would still often preclude transport in either mode, except to a homogeneous system.

Thus to represent a binary stream as text, IMO an obvious choice for that text representation would be in the form of text: X'hexdigits...', 0Xhexdigits..., 'hexdigits', UUENCODEd, or ???.

The only reason I would expect to see a BLOB represented in CSV is for database export and import; a primary reason for the existence of CSV. Database access over heterogeneous systems would generally preclude the need for text export/import methods [i.e. where a SELECT effects a _database_ transport mechanism], but CSV enables a Lowest Common Denominator approach to resolve a lack of interoperability whether that lack might be an issue of cost or ???.

Regards, Chuck