>Hi - I have been working with moving data back and forth between SQL SERVER and VFP9 and utilizing a sort utility that uses fixed width files for extremely high performance. This obviates the need for using SDF format when we copy data from Foxpro (the DBFs are very large) and performance is quite good.
>
>I have noticed a *reproducible* anomoly that is baffling, yet makes the above scenario unworkable. I am including exact code to reproduce the error. The conclusion is that when one does a COPY SDF of a DBF, integer columns sometimes have extra data padded onto them, ie., the resultant width isn't 11 bytes like it should be.
>
>Here is the code demonstrating the problem -
>

>CLOSE DATABASES ALL
>CREATE TABLE c:\temp\junk (fname c(15), lname c(25), int1 I)
>INSERT INTO c:\temp\junk VALUES ('JOHN','SMITH',1)
>INSERT INTO c:\temp\junk VALUES ('JANE','SMITH',2)
>INSERT INTO c:\temp\junk VALUES ('STEVE','SMITH',3)
>INSERT INTO c:\temp\junk VALUES ('SAMANTHA','SMITH',4)
>COPY FIELDS INT1, FNAME, LNAME TO C:\TEMP\JUNK SDF
>MODIFY FILE C:\TEMP\JUNK
>

>
>When you view the file C:\TEMP\JUNK.TXT, the first column, int1, has the integer column padded to 11 bytes but then adds four (4) spaces before the FNAME column starts!
>

>          1    JOHN           SMITH
>          2    JANE           SMITH
>          3    STEVE          SMITH
>          4    SAMANTHA       SMITH
>           ^^^^
>   (note the extra spaces)
>

>
>This is absolutely baffling. One of my coworkers said he has seen this since VFP6 and has always had to work around it. He has even reproduced it by taking a table, COPY SDF, and APPEND SDF and have it fail due to this 'phantom padding' of INT columns that occurs.
>
>Finally, if INT columns are the LAST COLUMN of the dump, it doesn't pad it. But we have some tables in which integers are padded by as many as 14 spaces when we COPY SDF.
>
>Any ideas? Am I seeing things?
>
>Thanks,
>
>Franz Nisswandt

It is a bug.
The bug seems to appear when the position of the field int1
doesn't correspond to its natural position, but the bug is into the logic of the C++ code.
For an INT field VFP uses the format of the field(copyOrder):

CLOSE DATABASES ALL
CREATE TABLE FORCEPATH("JUNK",SYS(2023)) (fname c(5), lname c(50), int1 I)
INSERT INTO (ALIAS()) VALUES ('JOHN','SMITH',1)
INSERT INTO (ALIAS()) VALUES ('JANE','SAMANTHA',-1234567890)

* same order SDF : Fill 5,50,11
COPY FIELDS FNAME, LNAME, INT1 TO FORCEPATH("JUNK",SYS(2023)) SDF
openText()

* different order SDF : Fill MAX(DIGITS(int1),5),5,,50
COPY FIELDS INT1, FNAME,LNAME TO FORCEPATH("JUNK",SYS(2023)) SDF
openText()

* different order SDF : Fill 50,MAX(DIGITS(int1),50),5
COPY FIELDS LNAME ,INT1, FNAME TO FORCEPATH("JUNK",SYS(2023)) SDF
openText()

USE

PROCEDURE openText
STRTOFILE(REPLICATE('1234567890',13),FORCEEXT(FORCEPATH("JUNK",SYS(2023)),"txt"),1)
* to use a not proportional font !!!! ( check the contect menu )
MODIFY FILE FORCEPATH("JUNK",SYS(2023))