>>>>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.
>>>
>>>Dragan, that's a long text, but was I miss is your admission that VFP's implementation contains a bug.
>>
>>Doesn't import from a loosely defined format in absolutely all cases? That's missing a feature, not really a bug. Such bugs can be found in all kinds of attempts to convey data in plain text format. I've seen Excel do crazy things with csv files, so what. The format has limitations, implementor beware.
>
>It is not missing a feature. It is a bug, simple as that. What is it that people here don't admit this??? There must be a deeper motive for that type of denial.
>
>Also keep in mind that not only the company where I'm currently working is upgrading their MS SQL Server version. So, this bug will gonna hit many more developers.

The very idea that a text file can be trusted to carry data, delimited by characters that may be expected to exist inside the data, is the initial bug. Everything else is a blind implementation of that idea. Anything trying to implement that without a firm contract between the sender and recipient will be buggy.

In this case, the bug is in the "copy to effe type csv" command - it produces this:

txt
"is weer "ziek""

i.e. it blindly wraps quotation marks around a string containing quotation marks. It doesn't even have a contract with itself. That, yes, that is a bug.