- EpiData-list - University of Manitoba Mailing Lists

data labels
by epidata-list＠lists.umanitoba.ca 08 Aug '05

08 Aug '05

Hi We're using version 3.1, downloaded from the Epi Data site. This is the first time we've used Epi Data. We are in the process of entering data into it. Initally, when we created a codebook from the QES file, the codebook displayed the values together with the value labels. But in subsequent attempts to create a codebook from the same QES file, we have found that the codebook won't show the value labels we entered into the QES file. Sometimes it won't even show the values. Do you have any ideas about this? Thanks! Catherine Mathews School of Public Health and Family Medicine University of Cape Town

1 0

Warmning: False Virus sent in name of EpiData
by epidata-list＠lists.umanitoba.ca 01 Aug '05

01 Aug '05

Warning of Virus sent in name of Epidata 1. Aug 2005 Users are warned against the spread of virus assumingly sent by epidata.dk. Known titles of these are IMPORTANT NOTIFICATION You have successfully updated your password Your Account is Suspended For Security Reasons And assumingly these are sent by: support(a)epidata.dk or webmaster(a)epidata.dk or admin(a)epidata.dk There is NO system at EpiData.dk which would send such information. Simply delete the mails without opening. I do not understand why someone are misusing the internet and collaborative efforts by spreading electronic virus. Quite disturbing to all of us. Regards Jens Lauritsen, EpiData Association

1 0

Status of EpiData Analysis development
by epidata-list＠lists.umanitoba.ca 08 Jul '05

08 Jul '05

Since release of first public test build of analysis in october last year good progress has been made. In judging progress it is important to recognize the nature of the EpiData Association, the size of economic contributions for development and the pricing principle - freeware. The latest build is available from http://www.epidata.dk/testing.php The list of what is fixed and remaing by build number is seen at: http://www.epidata.dk/analysisinfo/docs/versioninfo.htm The bug reporting database is shown at: http://asp.epidata.dk/support/default.asp The routine tests now include more than 350 conditions looking at as well overall, stratified and segmented conditions and comparing to external standard estimates. The aim of the complete test suite is to certify all available commands for a chosen number of representative datasets. The definite condition to meet before release is that the quality system certifies as well stability as correctness of estimation. But also that the implemented principles are logical in structure and documented such that decisions and requirements are clear to the end user. An example of this is the latest preparation of a detailed description of the principles of the output implementation of html and style sheets. The number of combinations of font selection, sizes and character sets is very large requiring control at the level of the end-user. This is available now, but for persons with very little or no knowledge in HTML and stylesheet principles the control of output can be a mystery. The status list includes : a. The main design principle of user interface, output formulation, number of commands, principle of missing data is final and most of it working. b.Finalisation of a simple way for users to define interface with local fonts etc. as part of the installation is almost finished. c. A coherent strategy for handling missing values across commands is being implemented. d. Some issues of table estimation exist. E.g. with correct turning of outcome and exposure. Some "Floating point and "Pointer" error messages occurs with some combinations of data e. Some aspects of graphing are giving problems. (Also relates to point b) Re c: e.g. if the user requests frequency tables for say 5 variables: 1. freq a b c d e 2. freq a b c d e /nomissing the first will show all data for all records, whereas the second will demand complete data for all five variables. This principle should be the same across all commands. And the implementation is needed as part of the testing of handling the data correctly. Kind regards -- Jens Lauritsen Coordinator and initiator of EpiData Project http://www.epidata.dk

1 0

Re:Problems with [-] key for entering missing values
by epidata-list＠lists.umanitoba.ca 04 Jul '05

04 Jul '05

Dirk Enzmann wrote: > Using the following .qes and .chk files with EpiData version 3.1, > EpiData's behavior is strange: > > If I use the [-] numeric key to enter missing values in the field > "schtype", EpiData jumps to the field "male" (i.e. "class" receives no > focus). If I use the [-] key in field "male", EpiData issues the error > message "'-' is not a valid floating point value" although missing > values are defined. > > The problem seems to be the movement to the next field after using the > [-] key, because if I drop field "coder" the problem of field "male" > does not occur. > > Is there a problem in the check file I did overlook or is this a > problem of EpiData version 3.1? Are there any solutions/suggestions? > two problems in above 1. I've noticed that the [-] key sometimes gives this error - the field is not accepted (the missing values are not recognized as legal). This seems to be a random occurrence. Closing the file and starting data entry again has solved the problem for me. 2. The problem of EpiData skipping a field after using [-] to enter a missing value can be addressed for now by checking whether the skipped field is blank before proceeding (see below). This problem only arises when the default missing value has the maximum number of digits in a numeric field. In Dirk's case, missing value is 9997 or 9999 in a #### field. Another solution is to make these special missing value codes negative numbers (e.g. -1) or smaller numbers (e.g. 999), which will be smaller than the field size. Then there is no skipping. This problem does not occur with fields of length one. Jamie Hockin Public Health Agency of Canada --------------------------------- * -- .chk -------------------------------- LABELBLOCK LABEL country * [0.2 ] 430 Austria 320 Belgium 3870 "Bosnia and Herzegovina" 11 Canada 3850 Croatia 3570 Cyprus 4200 "Czech Republic" 450 Denmark 440 "England and Wales" 3720 Estonia 3580 Finland 330 France 490 Germany 360 Hungary 3540 Iceland 3530 Ireland 390 Italy 3710 Latvia 3700 Lithuania 310 Netherlands 442 "Northern Ireland" 470 Norway 480 Poland 70 Russia 441 Scotland 3810 Serbia 3860 Slovenia 460 Sweden 410 Switzerland 10 "United States" 580 Venezuela END LABEL schtype * [0.3 ] 1 "slot1 (lowest grade)" 2 slot2 3 slot3 4 slot4 5 slot5 6 slot6 7 slot7 9998 "other schooltype" 9999 "no answer" END LABEL class * [0.4 ] 9997 "ambiguous answer" 9999 "no answer" END LABEL male * [1.0 ] 1 male 2 female 7 "ambiguous answer" 9 "no answer" END END * ======================================== BEFORE FILE HELP "ISRD2 pilot study nation" END * ======================================== casenum * [0.1 ] KEY Autosearch casenum RANGE 1 9999 MUSTENTER TYPE STATUSBAR "CaseNum = " END country * [0.2 ] * RANGE 1 9996 BEFORE ENTRY IF (ISBLANK(country)) THEN COMMENT LEGAL USE country SHOW ENDIF END COMMENT LEGAL USE country MUSTENTER REPEAT TYPE COMMENT END schtype * [0.3 ] RANGE 1 9996 MISSINGVALUE -1 * COMMENT LEGAL USE schtype MUSTENTER * TYPE COMMENT END class * [0.4 ] RANGE 1 9996 MISSINGVALUE 9997 9999 * COMMENT LEGAL USE class MUSTENTER AFTER ENTRY IF (class = 9997) THEN WRITENOTE "ambiguous answer" ENDIF END * TYPE COMMENT END male * [1.0 ] RANGE 1 2 MISSINGVALUE 7 9 * COMMENT LEGAL USE male * before entry * if (isblank(class)) then * goto class * endif * end MUSTENTER * TYPE COMMENT AFTER ENTRY IF (male = 7) THEN WRITENOTE "ambiguous answer" ENDIF END END coder * [66.0s] BEFORE ENTRY if (isblank(male)) then goto male endif TYPE "(alphanumeric)" GREEN END MUSTENTER WRITENOTE "@coder" END * -- end .chk --------------------------------

1 0

Problems with [-] key for entering missing values
by epidata-list＠lists.umanitoba.ca 03 Jul '05

03 Jul '05

Using the following .qes and .chk files with EpiData version 3.1, EpiData's behavior is strange: If I use the [-] numeric key to enter missing values in the field "schtype", EpiData jumps to the field "male" (i.e. "class" receives no focus). If I use the [-] key in field "male", EpiData issues the error message "'-' is not a valid floating point value" although missing values are defined. The problem seems to be the movement to the next field after using the [-] key, because if I drop field "coder" the problem of field "male" does not occur. Is there a problem in the check file I did overlook or is this a problem of EpiData version 3.1? Are there any solutions/suggestions? BTW: Unfortunately, if I want to label the missing values (an important feedback to the coder in case different types of "missingness") I cannot utilize the facility of EpiData to use the [-] key for entering missing values, because I cannot (better: should not) use COMMAND LEGAL and MISSINGVALUE with overlapping sets of values for the same field. This underscores the importance of the suggestions in my last mail (July 1, 2005) to the list. Here the code of the .qes and .chk files: * -- .qes -------------------------------- casenum country specific casenumber [0.1 ] #### country country code [0.2 ] #### schtype school type [0.3 ] #### class class [0.4 ] #### male gender [1.0 ] # coder Coder Initials: [66.0s] <A > * -- end .qes ---------------------------- * -- .chk -------------------------------- LABELBLOCK LABEL country * [0.2 ] 430 Austria 320 Belgium 3870 "Bosnia and Herzegovina" 11 Canada 3850 Croatia 3570 Cyprus 4200 "Czech Republic" 450 Denmark 440 "England and Wales" 3720 Estonia 3580 Finland 330 France 490 Germany 360 Hungary 3540 Iceland 3530 Ireland 390 Italy 3710 Latvia 3700 Lithuania 310 Netherlands 442 "Northern Ireland" 470 Norway 480 Poland 70 Russia 441 Scotland 3810 Serbia 3860 Slovenia 460 Sweden 410 Switzerland 10 "United States" 580 Venezuela END LABEL schtype * [0.3 ] 1 "slot1 (lowest grade)" 2 slot2 3 slot3 4 slot4 5 slot5 6 slot6 7 slot7 9998 "other schooltype" 9999 "no answer" END LABEL class * [0.4 ] 9997 "ambiguous answer" 9999 "no answer" END LABEL male * [1.0 ] 1 male 2 female 7 "ambiguous answer" 9 "no answer" END END * ======================================== BEFORE FILE HELP "ISRD2 pilot study nation" END * ======================================== casenum * [0.1 ] KEY Autosearch casenum RANGE 1 9999 MUSTENTER TYPE STATUSBAR "CaseNum = " END country * [0.2 ] * RANGE 1 9996 BEFORE ENTRY IF (ISBLANK(country)) THEN COMMENT LEGAL USE country SHOW ENDIF END COMMENT LEGAL USE country MUSTENTER REPEAT TYPE COMMENT END schtype * [0.3 ] RANGE 1 9996 MISSINGVALUE 9999 * COMMENT LEGAL USE schtype MUSTENTER * TYPE COMMENT END class * [0.4 ] RANGE 1 9996 MISSINGVALUE 9999 9997 * COMMENT LEGAL USE class MUSTENTER AFTER ENTRY IF (class = 9997) THEN WRITENOTE "ambiguous answer" ENDIF END * TYPE COMMENT END male * [1.0 ] RANGE 1 2 MISSINGVALUE 9 7 * COMMENT LEGAL USE male MUSTENTER * TYPE COMMENT AFTER ENTRY IF (male = 7) THEN WRITENOTE "ambiguous answer" ENDIF END END coder * [66.0s] BEFORE ENTRY TYPE "(alphanumeric)" GREEN END MUSTENTER WRITENOTE "@coder" END * -- end .chk -------------------------------- Dirk ************************************************* Dr. Dirk Enzmann Institute of Criminal Sciences Dept. of Criminology Edmund-Siemers-Allee 1 D-20146 Hamburg Germany phone: +49-040-42838.7498 (office) +49-040-42838.4591 (Billon) fax: +49-040-42838.2344 email: dirk.enzmann(a)jura.uni-hamburg.de www: http://www2.jura.uni-hamburg.de/instkrim/kriminologie/Mitarbeiter/Enzmann/E… *************************************************

1 0

Bug in EpiData 3.1? (TYPE STATUSBAR)
by epidata-list＠lists.umanitoba.ca 01 Jul '05

01 Jul '05

I noticed some differences between EpiData 3.0 and 3.1 and a possible bug in version 3.1: 1) If I use the check command TYE STATUSBAR "CaseNum = " the value of the field (here: casenum) is only shown in the statusbar if the focus is on the field. If I move to other fields, the value is not visible anymore. This occurs in version 3.1 but not in 3.0. This seems to be an error of version 3.1. 2) Version 3.0 and 3.1 differ in the way they display values defined by RANGE, MISSINGVALUE, and/or COMMAND LEGAL (field). For example, I have a multiple response question and the first question is a filter (if checked, the following multiple response questions do not apply). Or there is no filter variable but I want that the coder first has to decide whether any of the multiple response questions are checked (this is what I use in the following example). If not, I want that all values are set to missing (9 - no answer) and the focus should be set to the next block of questions. On the other hand, if there is at least one answer checked, the focus should move to the first of the multiple response questions and the user has to enter one of the folling values: 0 (no checked), 1 (checked), or 7 (ambiguous answer). When all data are entered, I want that the value labels are defined as follows (because I want that the SPSS syntax attaches value labels to missing values, as well; 8 is necesseary because the whole block of questions may not be applicable): * --------------------------------------- LABEL notice 0 "somebody found out" 1 "nobody found out" 7 "ambiguous answer" 8 "not applicable" 9 "no answer" END * --------------------------------------- However, to help the coder I want that while entering the data he/she does not see these labels but the following: ----------------------------------------- 0 - (not checked) 1 - no 7 - (ambiguous answer) ----------------------------------------- With EpiData version 3.0 this is possible if I use the following check commands: * ======================================= beerdt MISSINGVALUE 9 8 7 * <- (1) BEFORE ENTRY HELP "MULTIPLE RESPONSE QUESTION\n\nQuestion 46.6: Anything checked? (y/n)" KEYS="YN" IF (RESULTVALUE=2) THEN beerdt=9 beerdtpa=9 beerdtpo=9 beerdtte=9 beerdtse=9 GOTO beerpun ENDIF COMMENT LEGAL SHOW * <- (2) 0 "(not checked)" 1 no 7 "(ambiguous answer)" END END COMMENT LEGAL USE notice * <- (3) MUSTENTER TYPE COMMENT RED JUMPS 1 beerpun 9 beerpun END AFTER ENTRY IF (beerdt=0) THEN clear beerdtpa clear beerdtpo clear beerdtte clear beerdtse ENDIF IF (beerdt=1) THEN beerdtpa=0 beerdtpo=0 beerdtte=0 beerdtse=0 ENDIF IF (beerdt = 7) THEN WRITENOTE "ambiguous answer" ENDIF IF (beerdt=9) THEN beerdtpa=9 beerdtpo=9 beerdtte=9 beerdtse=9 ENDIF END END * ======================================= However, with EpiData 3.1, I cannot use "MISSINGVALUE 9 8 7" (see: * <- (1)) _and_ "COMMAND LEGAL SHOW" (see: * <- (2)) or "COMMAND LEGAL notice" (see: * <- (3)) simultaneously. If I use (1) and (2), the user sees: ---------------------- 0 - (not checked) 1 - no 7 - (ambiguous answer) 9 - missing 8 - missing 7 - missing ---------------------- and is able to enter 9 (which should not be used) or 8 (which would be wrong). If I only use (2), the value (9) or (8) cannot be set by the "BEFORE ENTRY .. END" command or by an IF .. THEN condition in another field. To use (3) would also be no solution to this problem. Thus, only version 3.0 seems to allow a solution to this problem. My main question is: Are there any reasons why I should prefer version 3.1 to version 3.0? Or which check commands do I need to solve the problem in version 3.1? With respect to the missing values it would be extemely helpful if EpiData could create SPSS syntax that defines missing values according to the definitions in the EpiData check file. However, if (like in version 3.1) I cannot use MISSINGVALUE and "COMMAND LEGAL labelname" (because I want to label the missing values and to show the coder the meaning of the values entered) simultaneously , there are no missing value definitions that EpiData could use to create the SPSS syntax file. I think that there are two solutions to this problem: (1) If MISSINGVALUE and "COMMAND LEGAL labelname" are used simultaneously, in displaying the legal values the values defined in the LABEL block get priority (and values MISSINGVALUE are not duplicated in the display). This would solve the problem described above, as well. (2) Alternatively, if the MISSINGVALUE is commented out EpiData uses only the values defined by RANGE or COMMAND LEGAL, but uses the values defined by the MISSINGVALUE command that is preceded by "*" for creating the missing value definition in the SPSS syntax. For example: * ---------------------------------------- LABELBLOCK LABEL variable 1 no 2 yes 8 "not applicable" 9 "no answer" END END variable COMMENT LEGAL variable * MISSINGVALUE 9 8 END * ---------------------------------------- would create the following SPSS syntax: * ---------------------------------------- VALUE LABELS variable (1) 'no' (2) 'yes' (8) 'not applicable' (9) 'no answer'. MISSING VALUES variable (9,8). * ---------------------------------------- Regards, Dirk ************************************************* Dr. Dirk Enzmann Institute of Criminal Sciences Dept. of Criminology Edmund-Siemers-Allee 1 D-20146 Hamburg Germany phone: +49-040-42838.7498 (office) +49-040-42838.4591 (Billon) fax: +49-040-42838.2344 email: dirk.enzmann(a)jura.uni-hamburg.de www: http://www2.jura.uni-hamburg.de/instkrim/kriminologie/Mitarbeiter/Enzmann/E… *************************************************

1 0

Export to SPSS, Variable names
by epidata-list＠lists.umanitoba.ca 24 Jun '05

24 Jun '05

Hello, I have a suggestion for the Epidata-Help-File, section "Export to SPSS": In Epidata you can use variable names (or field names) with a maximum of 10 characters. In newer versions of SPSS (12 or 13) you can use long variable names (64 Byte = 64 characters), in older versions only 8 characters. Exporting Epidata-fields with 10 characters to SPSS leads to shortened field names with 8 characters (for SPSS before Version 12). That causes a lot of work (e.g. renaming variables), if you think that 10 characters are exported. A hint in the Epidata-Help, that if the Data will be analysed in SPSS, the field names should have max. 8 characters, will be usefull. Greetings Juergen Spiegel *********************************************** Freiburger Institut fuer angewandte Sozialwissenschaft e.V. FIFAS Erasmusstr. 16, D-79098 Freiburg Telefon: (0761) 28 83 64 Fax: (0761) 29 27 493 Web: www.fifas.de e-mail: info(a)fifas.de

1 0

How to: Change id variable type from numerical to string
by epidata-list＠lists.umanitoba.ca 17 Jun '05

17 Jun '05

A question that came to epidata.dk: > In our EPI test.rec file we have made a 'clientnumber' field for a > maximum of 7 numbers entry (#######), for example to enter > clientnumber 3458. This test.rec file contains now several records. > But now we need to use the same field for entering a letters and > digits combination, f.e. P3467188. > I realise that we should have designed a string field <a >>. > > The clientnumber field not only needs to be longer than 7 numbers but > should be suitable for letters as well. > > Is it possible to change that in our current test.rec file? We prefer > that over making a new .qes file and an empty .rec file. > This is of general interest. the solution: 0. Make sure you have proper backup in case something goes wrong. 1. Either add a new field in the qes file with the letter part add a new field for combined letter + number add 2. or make qes and change to string field the same field update the rec file (just enter and epidata will ask ) 3. If you wish to add a certain letter to all previously added records add a recode block to the chk file or other file and run recode from the tools menu. See help file on recode e.g. if new string type id field is idNew and the old numerical one is id recodeblock idletter = "F" idnew = idletter + string(id) end plus to accomplish future records in same file: idnew noenter end idletter mustenter end id mustenter after entry idnew = idletter + string(id) end end -- Jens Lauritsen Coordinator and initiator of EpiData Project http://www.epidata.dk

1 0

RE: selecting on string variables
by epidata-list＠lists.umanitoba.ca 08 Jun '05

08 Jun '05

>>> <epidata-list(a)lists.umanitoba.ca> 25-05-2005 16:59:11 >>> Why is this necessary? I see "LION", upper case and delineated with " ". Thanks, Kelly Because assigning this : if recnumber = 2 then animal = "LION" to a stringvariable of length 10 gets the value: "LION " not the value "LION" Computers are stupid and the designer makes the choices. My choice is that "LION " is different than "LION" Someone would argue that we should always use the trimmed value of string variables, such that "LION " is the same as "LION" but this would give the user a problem if he/she wanted to compare the full length string. The strategy of EpiData for as well data entry as the coming release of analysis is that we make as few decisions as possible and let the end user decide. This is in contrast to other software developers who often impose new and changed strategies and changed ways of doing things on the users (Who is then forced to keep upgrading and learning new ways of doing what they could do with the old principle). EpiData tries NOT to invent new ways of doing things, but stick to the well founded principles of Epi6 (with appropriate extensions for those who wish to use the new principles of further documentation). Regards Jens Lauritsen Initiator of EpiData Coordinator EpiData Association

1 1

RE: [EpiData-list] value labels
by epidata-list＠lists.umanitoba.ca 03 Jun '05

03 Jun '05

Hi. It's possible to store comment legal values up to 80 characters long (EpiInfo / EpiData limit for string length). To do so, refer to a lookup table (see 'Comment legal' help section for that.) ______________________________________________ Gilles DELMAS Institut de Veille Sanitaire Dept. Maladies Infectieuses, Unité infections entériques, alimentaires et zoonoses 12 rue du Val d'Osne 94415 Saint-Maurice cedex - France + 33 1 41 79 67 27 g.delmas(a)invs.sante.fr ______________________________________________ -----Message d'origine----- De : epidata-list(a)lists.umanitoba.ca [mailto:epidata-list@lists.umanitoba.ca] Envoyé : jeudi 2 juin 2005 15:03 À : epidata-list(a)lists.umanitoba.ca Objet : [EpiData-list] value labels Hello to all! I have being using data entry software for my work and that of epi data is very interesting and smooth but my problem is that it can not take long value label with 256 characters. Is there anyone that can give me a suggestion of defining value labels for a variable with long characters. SEDZRO KOJO MENSAH P.O.Box AS 387 Ashaiman -Tema Ghana House : +233-22-300789 MOBILE : +233-244-458788 Open WebMail Project (http://openwebmail.org) ---------- Original Message ----------- From: epidata-list-request(a)lists.umanitoba.ca To: epidata-list(a)lists.umanitoba.ca Sent: Fri, 27 May 2005 12:02:51 -0500 (CDT) Subject: EpiData-list Digest, Vol 19, Issue 9 > Send EpiData-list mailing list submissions to > epidata-list(a)lists.umanitoba.ca > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.umanitoba.ca/mailman/listinfo/epidata-list > or, via email, send a message with subject or body 'help' to > epidata-list-request(a)lists.umanitoba.ca > > You can reach the person managing the list at > epidata-list-owner(a)lists.umanitoba.ca > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of EpiData-list digest..." ------- End of Original Message -------

1 0