What a coincidence (is it?). My colleague too decided to replace with a single quote. Argument: If a reading application does not convert into a single double quote, then the maximum field width may pose a problem.

Thanks for the code. My colleague does the modifications, but an initial brainwave I had was this code:

use somecursor
copy to effe for .f. type csv
copy to effe delimited with ~
lcC = filetostr( 'effe.txt' )
lcC = strtran( m.lcC, ["], [""] )
lcC = strtran( m.lcC, [~], ["] )
strtofile( m.lcC, 'effe.csv', 1 )

>Hoi Peter,
>
>>Het gaat redelijk. En met jou?
>
>Ik mag niet klagen.
>
>We are just replacing the double quotes with single quotes. I realize this is not ideal, but it is good enough for us.
>Our csv also handles memo fields with carriage returns, so that you can do mailmerges with paragraphs rather than a single line.
>
>As for performance, it of course is not as fast as a COPY TO CSV, but performance as we have found it, is reasonable.
>I'm not sure whether it will suit you, but you can give it a try.
>
>

>LPARAMETERS cFile, cScanClause
>LOCAL cResult, cMergeTemplate, nT, cField, cType, aFlds[1], nHandle, lRet
>
>cMergeTemplate = ""
>cResult = ""
>cScanClause = EVL(cScanClause,"")
>
>=AFIELDS(aFlds)
>
>FOR nT = 1 TO FCOUNT()
>	cField = FIELD(nT)
>	cResult = cResult + LOWER(cField) + IIF(nT = FCOUNT(), "", ",")
>	cType = aFlds(nT, 2)
>
>	DO CASE
>		CASE cType $ "C"
>			cMergeTemplate = cMergeTemplate + ;
>				'<<IIF(EMPTY('+cField+'),"",["]+RTRIM(CHRTRAN('+cField+', 0h220A0D, 0h27FEFF))+["])>>,'
>
>		CASE cType $ "M"
>			cMergeTemplate = cMergeTemplate + ;
>				'<<IIF(EMPTY('+cField+'),"",["]+CHRTRAN('+cField+', 0h220A0D, 0h27FEFF)+["])>>,'
>
>		CASE cType $ "L"
>			cMergeTemplate = cMergeTemplate + '<<CAST('+cField+' AS C(1))>>,'
>
>		CASE cType $ "DT"
>			cMergeTemplate = cMergeTemplate + '<<TRANSFORM('+cField+',"@Z")>>,'
>
>		CASE TYPE("lCopyToCsvTruncateTrailingZeros") = "L" AND lCopyToCsvTruncateTrailingZeros
>			cMergeTemplate = cMergeTemplate + '<<TRANSFORM('+cField+')>>,'	
>
>		OTHERWISE
>			cMergeTemplate = cMergeTemplate + '<<'+cField+'>>,'	
>	ENDCASE
>ENDFOR
>cMergeTemplate = LEFT(cMergeTemplate, LEN(cMergeTemplate) -1)
>
>nHandle = Fcreate(cFile)
>lRet = nHandle > 0
>lRet = lret AND FWRITE(nHandle, cresult) > 0 
>
>SCAN &cScanClause
>	IF TYPE("nCSVCodePage") <> "N" OR nCSVCodePage = 0
>		FWRITE(nHandle, CHR(13)+CHR(10)+CHRTRAN(STRTRAN(TEXTMERGE(cMergeTemplate), 0hfffe, 0h0A), 0hfffe, 0h0a0a)) 
>	ELSE
>		FWRITE(nHandle, CHR(13)+CHR(10)+CPCONVERT(CPCURRENT(), nCSVCodePage, CHRTRAN(STRTRAN(TEXTMERGE(cMergeTemplate), 0hfffe, 0h0A), 0hfffe, 0h0a0a))) 
>	ENDIF
>ENDSCAN
>=FCLOSE(nHandle)
>RETURN lRet

>
>
>
>
>
>
>
>
>>
>>It is now a real issue because the company is implementing a more recent version of SQL Server and its import routine no longer accepts single double quotes whereas the previous version did. That the former version did accept it, is something we didn't know at that time. Else, we'd have seen this behavior long time ago and acted upon it. Nowadays there are many interfaces that are done using CSV, so it's not a simple repair.
>>
>>Here's an extended version of my 'proof'. The 3rd record shows that vfp does not handle double double quotes properly.
>>

create cursor c_effe ( txt c(20) )
>>insert into c_effe value ( 'is weer "ziek"' )
>>copy to effe type csv
>>append from effe type csv
>>strtofile( 'txt'+chr(13)+chr(10)+'"is weer ""ziek"""', 'effe1.csv' )
>>append from effe1 type csv
>>browse

>>
>>Is your csv generator fast and generic?
>>
>>>Hoi Peter,
>>>
>>>Hoe gaat ie?
>>>
>>>For this (and other) reasons, we just build our own CSV generator, but it was after the release of V9 and did not found it to be a big enough problem to put it on the ER list.
>>>
>>>Walter,
>>>
>>>
>>>
>>>
>>>>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.
>>>>
>>>>>And your point is?
>>>>>
>>>>>>IMO, VFP, including 9, has a bug with regard to the export and import of CSV-files.
>>>>>>
>>>>>>Here is the code that proves this:
>>>>>>

create cursor c_effe ( txt c(20) )
>>>>>>insert into c_effe value ( 'is weer "ziek"' )
>>>>>>copy to effe type csv
>>>>>>append from effe type csv
>>>>>>browse

>>>>>>
>>>>>>How come nobody ever told this to the vfp-team???
>>>>>>
>>>>>>And yes, I know how to prevent this. But isn't that actually a silly situation? It should've been VFP that does the correct handling of double quotes.
>>>>>>
>>>>>>See also: http://en.wikipedia.org/wiki/Comma-separated_values and http://tools.ietf.org/html/rfc4180