Jamie,
Thanks for the quick response. Yes, we are using epidata 3.1 for all data entry up to this point. We are before the stage of double entry validation, but I need to append the data from 18 computers and calculate the number of questionnaires entered to pay the individual staff. Also I am writing my analysis syntax on the unclean data so it won't take so long to write the report when the data entry/cleaning is finished.
Yes, I should have put a consistency check in for those dates, but I did not. Now I have a mountain of 1st entry data that I have to fight with.
I am using analysis to write and run the APPEND.PGM. I thought it would work through EPI-C, but I cannot get EPI-C to recognize the append command. These types of .pgm's used to run through EPI-INFO, but don't appear to run in EPI-DATA. If I am wrong, please correct me.
date.qes date <dd/mm/yyyy> date 1.rec & date 2.rec
In Analysis: read "date 1" Loading data C:\c temp\date 1.REC, please wait.. invalid year 1111, month 11, day 11 invalid year 2222, month 2, day 22 invalid year 4000, month 3, day 12 invalid year 500, month 3, day 12 invalid year 6000, month 3, day 12 File name : C:\c temp\date 1.REC date Fields: 2 Total records: 6 Valid records: 6 . append "date 2" Loading data C:\c temp\date 2.REC, please wait.. invalid year 212, month 12, day 12 Appended file: Fields: 2 Total records: 1 Valid records: 1
Combined file: Fields: 2 Total records: 7 . savedata "dateall" Saving data to: C:\c temp\dateall.rec invalid date Failed to save data to C:\c temp\dateall.rec
This is the Invalid date that I refer too.
Thanks for your time.
Robert
----------------------------------------------------------------------
Message: 1 Date: Sat, 7 Oct 2006 03:05:50 -0700 (PDT) From: epidata-list@lists.umanitoba.ca Subject: [EpiData-list] Invalid date error To: epidata-list@lists.umanitoba.ca Message-ID:
20061007100550.72167.qmail@web51301.mail.yahoo.com
Content-Type: text/plain; charset=iso-8859-1
Dear Epidata Listserve,
The function on Epidata that only allows valid dates is not allowing me to save data after the append command. The data entry keyers sometimes enter a wrong date. The invalid date does not become a problem (i believe) until I run
the
savedata command. Then the invalid date error pops up and the data is not saved.
read "WOMAN 1.rec" /close append "WOMAN 2.rec" append "WOMAN 3.rec" etc... savedata "WOMANALL"
Is there any way to turn off the valid date requirement or work around this?
Thanks for the program and your support. Robert Johnston Phnom Penh, Cambodia.
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam
protection around
Message: 2 Date: Sat, 07 Oct 2006 08:27:16 -0400 From: epidata-list@lists.umanitoba.ca Subject: Re: [EpiData-list] Invalid date error To: epidata-list@lists.umanitoba.ca Message-ID: 45279D24.4080207@sympatico.ca Content-Type: text/plain; charset=ISO-8859-1;
format=flowed
Were the data entered in EpiData? If so, how could
there be invalid
dates? If the data were entered using another
program you should still
be able to validate the data with EpiData Entry,
using a .chk file with
a CONSISTENCYBLOCK and a CHECK command. In the Entry
Help file use the
Contents link to "Document datafile" and "Logical
consistency check".
It's a good idea to clean up this type of error
before using Analysis.
Jamie
Robert wrote
The function on Epidata that only allows valid dates is not allowing me to save data after the append command. The data entry keyers sometimes enter a wrong date. The invalid date does not become a problem (i believe) until I run
the
savedata command. Then the invalid date error pops up and the data is not saved.
Message: 3 Date: Sat, 07 Oct 2006 16:12:38 +0200 From: epidata-list@lists.umanitoba.ca Subject: [EpiData-list] Design decision and
information (EpIData
Analysis) To: epidata-list@lists.umanitoba.ca Message-ID: 4527B5D6.6030804@epidata.dk Content-Type: text/plain; charset=ISO-8859-1;
format=flowed
In the design of v2.0 of EpiData Analysis I wish to
simplify and clarify
the use of options and "set" definitions to a
unified approach. And this
principle is more important than backwards continuation of an unclear principle.
The reason is among
other that v2.0 will include more statistics, e.g. gamma
coefficient for
ordinal data and exact statistics for tables in general.
Another intention is to have more options and fewer
commands, but to assist
users by more intuitive dialogs. E.g. as now where
graph commands can be
specified with a structured dialog where most
options are available. The
intention is that : v2.0: will include more functionality at the command
level, but the
dialogs helping beginners will come later.
The problem with the current way of implementation
is that there is a
non-unified approach to what is defined at command level and
what at "set" level.
Mostly due to the way it was done in Epi6. And this
confuses users.
When the first release of v2.0 is ready all users
will be able to
comment on the actual implementation of the principles. The release
of v2.0 for test
will be made when we have reached a certain level of
clarification. We are not quite
there yet. But good progress is being made.
I would like users to comment on these decisions:
.................................................................................................................
option: A specification for a given command. These are a
combination of / and
letters or numbers All options are made as short as possible and there
is no intention to
try to make the option name understandable, but in the documentation they should
all be explained. A
given designation for an option should mean the same in all commands if
possible.
e.g. /m is always allow missing values
set: a general specification for running the programme or
setting formats.
The first word of a "set" tells what this specifices. General which cannot
obey this rule should
be avoided. e.g. set display databrowser = on/off (will always
show data browser
in the background).
.................................................................................................................
All showing of labels, values etc are defined by
these "set" commands:
set var label = on/off ( show or hide variable
label)
set var name = on/off (removes name of var if
the same as first word
in variable label) set var value = on/off (controls whether actual
numerical value are
shown) set var label = on/off (controls showing of
"comment legal/value labels")
e.g. set var value = off: show only value labels in
tables (but show
values if no value labels are defined)
.................................................................................................................
Creation and display of statistical tests,
percentages etc are moved to
each command: e.g. means age sex (only descriptive summaries
are shown)
means age sex /t (will display t test if one
group and f test
+Bartletts test with more groups) tables agegrp sex (only showns counts) tab agegrp sex /chi (shows chi square values) tab agegrp sex /r /c (would add row and column
percentages)
tab agegrp sex /t (would add total percentages
with no decimal points)
.................................................................................................................
Format of estimates and confidence intervals and
table column headers
are defined as "set": e.g. TABLE PERCENT HEADER ROW % TABLE PERCENT FORMAT ROW P1{}
.................................................................................................................
Format of Confidence Intervals are
TABLE CI HEADER (95% CI) TABLE CI FORMAT C2-()
.................................................................................................................
Regards
Jens Lauritsen EpiData Association
EpiData-list@lists.umanitoba.ca
http://lists.umanitoba.ca/mailman/listinfo/epidata-list
End of EpiData-list Digest, Vol 36, Issue 6
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Robert,
There is no way to identify and fix the invalid dates in Analysis and it will refuse to handle a date outside the legal range (01/01/1800 to 31/12/2199)
Create a check file with the following: ==== checkdates.chk ==== recodeblock if (d < "01/01/1900") or (d > "31/12/2006") then d = date(1,1,1800) endif end
consistencyblock check "Invalid date" checkrange end
d range "01/01/1900" "31/12/2006" end ==== end of checkdates.chk ==== In my example, D is a date variable. If I had used the check file for entry, all dates would be valid because of the RANGE command. However, since I entered data without this check, I can use the CONSISTENCYBLOCK to find records with an invalid date (prints a report with the record numbers) or I can use the RECODEBLOCK to change D to a date that I know is wrong, but that EpiData will accept until I can fix it. There is no need to retain the originally typed value, since you have to go back to the original data source.
To do a recode, use the Tools menu; to do a consistency check, use the Document menu (both in EpiData entry).
You can use EPIC to do the consistency checks, but not the recoding.
Unfortunately, the date variables will be useless in Analysis until you clean them up.
We can ask that invalid dates be converted to Missing or some other useful code when they are outside the legal limits for Analysis.
Jamie
participants (1)
-
epidata-list＠lists.umanitoba.ca