recently we provided some sas converted to SPSS data sets to users. i was told that @ least 1 user is finding that some of his numeric observations has numbers plus 12 trailing decimals. unfortunately i have not been sent this data yet so I am trying to explain this as best as i was told.
i am aware that he should be able to use a format stmt such as comma10.2 or 8.2 to combat this but i am wondering why this has occurred. i don't have spss so i am unable to test this for myself.
we used stat transfer to convert the data & i have found that some variables lengths were changed when converting the sav. file back to sas. not sure but our guess is that the offending variables maybe our calculated variables (i.e. sum(x,y)/.31)). these variables are formatted to 8.2 and it could be that the format is corrupting during transfer.
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