Q: Why is Epi2002 breaking down on freq * with a file containing boolean
fields.
One question or aspect could be that field types <Y> in access (and
thereby epi2002) are treated as having two values, either Y or N.
I have very little experience in using Boolean field types, but have
had problems when exporting one file for a colleague from access due to
the fact that all entered as Y were exported as Y and all others were
exported as N regardless of data were entered or not.
My suggestion is therefore:
a. make a small file in epi6 with the same three fields
b. enten in epi6 data - say 5 records
c. try the same freq * in epi2002 with that file
d. try with the "epidata" file in epi2002 to recode missing value to
"N"
tell us if what works and what does not. If it works send me the new
file and the one breaking down epi2002 and we will compare.
If it does brake down my idea of not accepting a "missing" in a Boolean
field is propably right and you could then in
recoding could also be done in epidata:
recodeblock
if m1ham = . then
m1ham = "N"
endif
end
and run the recode in tools
regards
Jens Lauritsen
info(a)epidata.dk
Hello there list users
I have a problem when I use Epi2002 to analyse data created through
epidata. The problem is that the command freq * causes an error that
means you have to close down. The same files are OK to analyse in Epi
6.04 and there is no problem with the FREQ * command. I wonder if the
problem could be that I set up my . qes files without a label. I always
used to do this in Epi6 and thought it would be OK in Epidata as I
kept the variables to 10 letters or less as below.
SEX #
AGE ##
M1HAM <Y>
Has anyone had a similar problem? OR does anyone have a comment about
creating .qes files with just variables and no labels?
thank you
Christine
+++The information contained in this email and any attachments is confidential and may be legally privileged. If you have received this message in error, please notify the sender immediately and remove all copies of the message, including any attachments. Any views or opinions expressed in this email (unless otherwise stated) may not represent those of Hutt Valley DHB. Thank you.+++
Disclaimer added by HVDHB
