Public Release Version *2.2.1* build 170 - Aug 23th 2009
o Histogram Now groups data into bins.
o /CLOSE added to Generate command.
o Added: /FONTSIZE and /SUBFOOT added to graph commands.
* Bugs fixed
o Removed Sigma3 from legend in runchart command.
o Freq sorted incorrectly by default, and using /SA or /SD.
o Variable name with "if" in, cause pre-processor to
incorrectly insert "set option" text the wrong place.
o Labelvalue command gave no error with incorrect construction.
o Use of /W in tables command deleted wrong variable in some
I have been working on a data entry form that was previously in Access.
It has a lot of check box fields in Access (boolean fields that are
represented on the screen by a box that alternates between being checked
(true) and empty (false) when clicked.
There is a way to do this in Epidata, which can be useful when
presenting a long list of symptoms/signs or exposures to be completed.
The trick to doing this is to create Yes/No fields that cannot be
entered using the tab or cursor keys. They can, however, be entered
using the mouse. In this example, clicking in one of these fields will
toggle the value of the field between "Y" and missing.
Perhaps others will find this useful.
11 1 VLAB
_label1 1 1 30 0 0 0 0 112 Emulate check boxes
#id 1 3 30 4 3 12 5 112 id
#age 1 5 30 5 5 0 2 112 age
_sex 1 6 30 5 6 3 1 112 sex
_label2 1 8 30 0 0 0 0 112 Check as many boxes as you want
_a 1 10 30 3 10 5 1 112 a
_b 6 10 30 9 10 5 1 112 b
_c 12 10 30 15 10 5 1 112 c
#xnotused 1 12 30 10 12 0 1 112 xnotused
#action 1 14 30 8 14 0 1 112 action
_label3 9 14 30 0 0 0 0 112 Anything to finish up
1 12M Y !
2 11FY Y !
3 10MYY !
* Emulate check boxes
range 0 99
* this is the last field before the check boxes
* jump to the field beyond the check boxes
* this is a checkbox field that can only be entered
* by clicking the cursor
* If Epidata gets to this field, it must be that the
* user has clicked in the field. This means that the
* value of the field is toggled between Y and missing.
* Note that any other cycle of changes is possible
* Y to N to Y, Y to N to blank to Y, etc
* Just program the nested if ... then ... endif blocks
* These blocks MUST be NESTED and not sequential.
if a = "Y" then
a = .
if a = . then
a = "Y"
if b = "Y" then
b = .
if b = . then
b = "Y"
if c = "Y" then
c = .
if c = . then
c = "Y"
* This field is used to block going to field c
* with the cursor. Cursor UP from field ACTION will
* come here and immediately go back to field ACTION
Emulate check boxes
Check as many boxes as you want
a <Y> b <Y> c <Y>
action # Anything to finish up
I will be out of the office starting 2009-08-19 and will not return until
Though I will have access to email and will try to respond to
correspondence, for urgent CFEP matters please contact Gisele Jolicoeur at
Hello for my first post,
In .recfile I had a numeric variable X like /_##_/
In SAS program I get
/INPUT X _1_/ etc...
that implies in the SAS table a variable like . (missing variable).
On correcting with _/1-2/_, it works.
Thanks for explanation.
During the most recent year development has been focused on SPC methods
in Analysis (SPC: Statistical Process Control graphs and analysis), but
also directed towards the longer sustainability issue of converting all
EpiData Software to Open-Source and a unified approach, including a new
principle of translation (not put into practice yet).
Such that regardless of variety (Entry, Analysis, EpiC) the same
function will do the same. The other aspect is to run on several
operating systems (linux, windows, Mac). A major break through in this
respect was reached upon release of the first test version for Linux and
Windows in May/June this year.
In the near future (weeks/days) two aspects will become visible:
a. Minor update of EpiData Analysis with key reported problems such as:
Histograms (are essentially bar graphs until now),
Parsing of varible names containing "if",
Setting font size in graphs via dialogs
b. Next step in the core project, where users can test the future
"engine". The current and next release allows reading and writing of
text files, including "intelligent" guessing of variable format. A new
aspect is that decimal separator can be defined by the user. With a bit
of luck also a Mac variant of the core module will appear in a few weeks
(if no major problem shows up).
The principle now is that known problems mainly are solved in the core
project rather than a temporary solution in e.g. Analysis.
The coming phases of development are expected to be:
- getting to the point where translation can be applied
(the principle is visible - but not implemented fully
- rewriting EpiC to use the core module
- develop a batch testing principle for reading and writing files
- Inclusion of the new core in Analysis
- Development of a GCP/FDA part 11/EMEA (Good Clinical practice for US
and EU officially approved data entry) compliant data-entry client. The
GCP principles will follow guidelines as shown on the European Clinical
Network research ECRIN - page and published by an international working
group in which I was a member, see http://www.ecrin.org - publications
and find: GCP-compliant data management in multinational clinical trials.
ECRIN-2, Deliverable D10, Version 1, 15 September 2008.
In between these aspects some further development of Analysis and other
products (Entry and EpiC) will take place, but focus will be on getting
it all together on the new core to ensure sustainable development.
Actually the current year marks a decade since first relase of EpiData
Software and the autumn might contain special activities to celebrate
I should mention that the project as a whole could not have been
completed without the efforts of donors, the user base, the critical
input, the specific work of people involved (see
In particular for the rewriting focused donations from a number of
institutions mentioned on the www.epidata.dk/funding.htm page has been
essential. Such that full time employed Torsten Christiansen has been
extended beyond the first year to a full two year period. Without the
skillful efforts of Torsten in the first year leading to funding for a
second year the whole rewriting would not be possible. I could also add,
that without the thorough programming efforts by Michael Bruus in Entry
and EpiC in the first ten years the rewriting would also not be possible
in a two year period.
The coming year again seems to give the EpiData Society as a whole
(users and developers) another fruitful season.
Warm Regards to all
Coordinator and initiator of EpiData Project
I created a data entry system for a project which includes five relational databases.
When we open EpiData and choose "enter data" all of the screens open, but we get the following message:
Access violation at address 00464077. Write of address 0000000C
I will appreciate any help I can get on this issue.
I'm just starting to use epidata entry so I have probably overlooked
something. Any pointers are appreciated!
I defined a date field as follows in the .qes file:
DOB date of birth <dd/mm/yyyy>
in the .rec file I added the following sanity check:
IF ((year(DOB) < 1900) OR (DOB > TODAY)) THEN
HELP "This date is not allowed" TYPE=ERROR
Most of the time the field behaves as I expect it to: dates in the
future or far in the past are not allowed. However, the following typo
gets accepted without triggering an error: 05/08/20001. Adding an extra
trailing zero (05/08/200010) results in a prompt conversion to
05/08/3402, and the sanity check works again. Some experimentation seems
to confirm that values between 20000 and 20099 are accepted as valid for
year, bigger values trigger either my check or are converted to some
weird value, again triggering the check.
How can I prevent this from happening?
thanks in advance,
version info: epidata v3.1 (270108), on windows XP.