>>>>I think I have come across a bug in VFP9 SP1.
>>>>Using the COPY TO command when a field is one character long and it's empty the output file will have a space in that position but if the field is two or more characters long the position will not have the space.
>>>>
>>>>

>>>>CREATE CURSOR test1 (f3 c(3),f2 c(2),f1 c(1),n1 n(1,0),n2 n(3,1))
>>>>APPEND BLANK
>>>>COPY TO test1.txt DELIMITED WITH "" WITH CHARACTER "|"
>>>>

>>>>
>>>>Output File:
>>>>

>>>>|| |0|0.0
>>>>

>>>>
>>>>Note that the field f1 in the output file shows a space when it should be empty like f2 and f3.
>>>>
>>>>Has anyone else ever ran into this before?
>>>>
>>>>Dennis
>>>
>>>So what the bug is?
>>>Cetin
>>
>>expected
>>

>><   |  | |0|0.0>
>>

>
>Within a delimited file have a lot of redundant spaces? I don't see a difference having 0 or more spaces to represent blank data. Ideally I'd expect:
>

>|||0|0.0
>

but I don't see wasting a space as a bug.
>Cetin

On VFP9 binary VFP doesn't trim 0h0 and copy the hex syntax,
and for a varchar is not trimmed also;
but a char ( binary ) is trimmed and then ( before VFP9 )
you cannot copy into a text a binary field.

CREATE CURSOR test1 (f1 c(1),v3 V(3) DEFAULT 'v ',c3 c(3) DEFAULT 'c  ' NOCPTRANS ,q3 q(3) DEFAULT 0h0000 )
APPEND BLANK
COPY TO test1.txt DELIMITED WITH "" WITH CHARACTER "|" 
MODIFY FILE test1.txt

I think that this is not a casual bug
but an awkward attempt (of the team) to interpret the developer mind;
as a CHAR(1) as flag is used, often a space can be meaningful
and in data exchanges doesn't trim could simplify the operation.
Vice versa, CHAR(N=2,3,...) hardly it is a flag,
and therefore the team has thought of trim the field.

But,
who write a dev env it doesn't have to think about thing it can do.
COPY is a copy, then if a field is SPACE(3) copy must put 3 spaces into the target.

Fabio