pspp-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: String variables combining files


From: ftr
Subject: Re: String variables combining files
Date: Thu, 26 Mar 2015 09:59:14 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0



On 25/03/2015 17:25, Alan Mead wrote:
On 3/25/2015 10:00 AM, ftr wrote:
Frans,

I don't understand why you don't change the variable width for your string variables. This seems the most easiest way for everyone.
Cheers,
ftr

If you have dozens of variables in dozens of files, it's not "easy" to fix this problem.

I find this most often arises when I have used CSV or a Spreadsheet to hold data for several different instances that later needs to be integrated.  For example, I've been involved in projects where data was gathered each semester at a few schools.  To later join that data is a nightmare if there are many string variables. 

Also, if you know that this is going to be an issue, you can do more to avoid it. The annoying thing about this issue in SPSS (and PSPP) is that you find out about the problem when the join fails. If you don't know to avoid this, it can be maddening to repeatedly run join and have to fix each issue individually.

-Alan

So this means that the programs that produce the CSV files produce output with different string variable width ?
This is due to the programs or to the people that use the progs ?

In general, when you import text files you fix the variable width in the DATA LIST.
Or you use GET DATA/TYPE=
http://www.gnu.org/software/pspp/manual/pspp.html#GET-DATA

And why don't you set FORMAT on each of the separate files before you integrate them ?
 
When I worked in a project that sounds similar to yours we did a serious pre-field work training of the local data producers that succeeded in making the local projects aware what was on stake (motivation), that made the local heads control the consistency of data to be sent - something we could not do because we had no direct access to the local projects, for which the local heads had better knowledge,  and it would have cost us too much (data control) - and that assured that data were sent in a coherent format and at time.

Maybe you have to train your local people ?

Just some ideas for local problem solving. I am happy that we have volunteers doing the programming work so we should not overcharge them with more work that we can at our side.

Regards,
-ftr

reply via email to

[Prev in Thread] Current Thread [Next in Thread]