>I'm amazed that nobody here has EVER in the past decade made a comment about this incorrect behavior. There are several posts about the problem, but never it was said that it's a bug, including your posts.
>
>It is important for developers to be aware of the incorrect behavior, because it makes it a requirement to do no direct COPY TO TYPE CSV or APPEND FROM TYPE CSV. Instead, one should write a bug-aware function that does create or read.

The point here is that the format is "value","value",number,"value" etc etc - i.e. the strings are surrounded with quotation marks. So whatever imports these, expects that the string value is whatever bytes there are after the quotation marks until the next quotation mark is met. Now if your string value contains one, tough luck.

It's the same problem with memo fields in a text file, when you have the CR and/or LF as record delimiters, and yet a memo field in a record also contains one.

Basically, the eternal problem of distinguishing between content and packaging, because the content contains some of the packaging. So they introduce various escape sequences (like duplicating apostrophes in SQL, prefixing formatting stuff with backslashes and wrapping the blocks with braces in RTF, introducing entities in HTML etc etc) so that there's a way to distinguish between the content and the wrapper, which is basically a contract between the sender and the recever. And then someone wants to have the packaging as content (i.e. your text is about the wrapper, your RTF text contains examples of RTF codes, your HTML is an article about HTML syntax).

Over the last 20+ years I had to export, and more frequently import, data in various text formats, and the most frequent situation was that I had to reverse engineer that contract, i.e. to guess the rules used to create the text. The most frequent solution was something beginning with FileToStr()... and a lot of chrtran(), strtran(), aLines(). Append from... works only for simplest cases, which were always rare.