From my experience with proc export and proc import with dbms=sav
and the regular use of stattransfer and the examination of export and import in spss v16
i would say that
Stattransfer in import is doing the work well , after analysing completely the colums,
in adjusting (and of course reducing the 'length' of the numeric variables) the size of the new file including too the users formats.
Only once i encounter a not working output probably related to missing values.
In spss the input is working well with the menu except that you have to submit a couple of lines in order to import a table with a userformat file.
The proc export of sas (9.1.3)is creating a file with old standard of spss (variable name, maintaining numeric length... and so on). Sometimes is this file not acceptable to Spss.
or There are too much changes in it.
Therefore the ultimate way is creating under stattransfer 2 files a . sas and a .dat
In the other way spss==> sas,
The import in sas by proc export is creating a big sas7bdat (8 for numeric even if the spss users are often creating numeric variable of 1 position) and a format catalog in the work if necessary but with sometimes strange format names.
Spss is exporting (if necessary) 2 file a sas7bdat + a .sas with the formats creating process
Stattransfer is creating the same.
Both last are narrowing the numeric variables if possible when not decimal, at a range of 4 or from 3-7
Stattransfer offer another possibility a .dat and a complete .sas program file which can be corrected if a problem is encounter.
I never encounter a problem of format destroying the information in stattransfer: this seems your case.
But it is true that the missing values (if not the dot) are modified/changed in the two ways
.a-.z are not becoming users missing spss values but system missing
users missing values like -999,98 99 are transformed into . or some .b .m following the soft you utilise
Please forward when you get the file, the exact change in spss from which exact
sas start point
HTH
Andre