>>>>>>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.
>
>What a nonsense! The COPY TO CSV should have added the second double quote. THERE is the 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.
>
>Again, what a nonsense! The APPEND FROM CSV should have converted the double double quotes to a single double quote. THERE is the accompanying bug.

OMIPU

Stop complaining. File it to MS. Possibly they will recreate the VFP team to do a bug fix for you.

It is this way all those years from start, it was never said that it will do more then wrapping in double qoutes. Even the double qoutes are not part of the real structure. It is comma delimited. As long as you do not have comma in text, you don't need double quotes at all.
There are two things you can trust on csv. There is a sort of delimiter that will separate fields, and there is an other delimiter that will separate records.

If the records are separated by CRLF,LFCR,CR or LF is not defined. If fields are separated with, ; [tab] is not defined. If all fields are wrapped in field delimiters like " or just text or none is not defined. There is a common use only.
Same to number of fields per record. Common use is to have same number. But not all follow that.

If you run it with standard german SYSFORMAT you will end up with an extra column per numeric field since decimal point comes as comma. Date fields will be bound to SYSFORMAT too.

This is a number one numb-last-resort file type, If you have more tricky things to interchange, you need to spend some hours of your lifetime. As simple as that.