December 2005 - EpiData-list - University of Manitoba Mailing Lists

Re: EpiData-list Digest, Vol 26, Issue 15 (out of office)
by epidata-list＠lists.umanitoba.ca 31 Dec '05

31 Dec '05

I will be out of the office from the afternoon of December 23 until the morning of January 3. elaine >>> epidata-list 12/31/05 12:00 >>> 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..." EpiData-list mailing list ___________________________________ Today's Topics: 1. V1.1 of EpiData Analysis ready (?) (epidata-list(a)lists.umanitoba.ca) ---------------------------------------------------------------------- Message: 1 Date: Sat, 31 Dec 2005 12:23:58 +0100 From: epidata-list(a)lists.umanitoba.ca Subject: [EpiData-list] V1.1 of EpiData Analysis ready (?) To: epidata-list(a)lists.umanitoba.ca Message-ID: <43B66A4E.8060909(a)epidata.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Unless someone finds serious bugs in the testversion of EpiData Analysis v1.1 build 61 available from: the testing page: Http://www.epidata.dk/testing.php will be released for general usage about one week from today. Translation procedures have started and a preliminary partial installation procedure in Spanish can be tested. Many aspects are updated and enhanced. See: Http://www.epidata.dk/testing.php for a complete list. The major issue is a new focused help system, an aggregation (collapse) command and extensions such as a cumulative column in frequency tables. Work on revision of the stratified table analysis module will be made within the first quarter of 2006, in particular due to a recent donation from Health Canada and the Statistical Process Charts will be extended due to the collaboration with Gruk Norway. Regards and happy new-year to all Jens Lauritsen EpiData Association ------------------------------ ________________________________________ EpiData-list(a)lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list End of EpiData-list Digest, Vol 26, Issue 15 ********************************************

1 0

V1.1 of EpiData Analysis ready (?)
by epidata-list＠lists.umanitoba.ca 31 Dec '05

31 Dec '05

Unless someone finds serious bugs in the testversion of EpiData Analysis v1.1 build 61 available from: the testing page: Http://www.epidata.dk/testing.php will be released for general usage about one week from today. Translation procedures have started and a preliminary partial installation procedure in Spanish can be tested. Many aspects are updated and enhanced. See: Http://www.epidata.dk/testing.php for a complete list. The major issue is a new focused help system, an aggregation (collapse) command and extensions such as a cumulative column in frequency tables. Work on revision of the stratified table analysis module will be made within the first quarter of 2006, in particular due to a recent donation from Health Canada and the Statistical Process Charts will be extended due to the collaboration with Gruk Norway. Regards and happy new-year to all Jens Lauritsen EpiData Association

1 0

rec file as email-attachment
by epidata-list＠lists.umanitoba.ca 19 Dec '05

19 Dec '05

1 0

New build of EpiData Entry and advancements on Analysis and a new help window
by epidata-list＠lists.umanitoba.ca 17 Dec '05

17 Dec '05

The reported problems of EpiData Entry when verifying double entry has been solved. The problem was that when the file to compare with was missing, then a mysterious error message was given. The principle has now been changed such that if the comparison file is not existing, then the verify procedure stops completely. The path information in the ...dbc file is no longer placed there. Therefore if the user wishes to compare to a first entry file residing in a different folder than where the ...dbl.rec file resides, then manually edit the ....dbc file. Analysis is advancing A lot of work has been put into finding a managable help file structure, which also accomodates translation. If you see on the http://www.epidata.dk/testing.php page, you will see that there is now a partial translation to Spanish and the English version. Some issues of always showing the correct file is still lacking, but is expected to be fixed within a few weeks. The test versions are placed on: http://www.epidata.dk/testing.php The upgraded EpiData Entry (build 18dec2005) is on the http://www.epidata.dk/download.php Version information for entry: http://www.epidata.dk/revision.htm analysis: http://www.epidata.dk/versioninfo.htm Kind regards Jens Lauritsen EpiData Association

1 0

RE: [EpiData-list] Date variable
by epidata-list＠lists.umanitoba.ca 15 Dec '05

15 Dec '05

It's more simple to to it step by step: 1- Your qes file has to contain a variable (string, length = 4. I call it YV1)) to store the year of the date entered in V1. 2- In the chk file, edit checkblock for V1, and add the line: YV1 = year(V1) 3- Then, it is possible to enter the check lines that will calculate the categories: If YV1 = "xxx" then CATEGORY = "xxx" Endif If YV1 = "yyy" then CATEGORY = "yyy" Endif (...) End (assuming there is a variable called Category!) That's it. It's better (although you can do without) to add NOENTER to YV1 checkblock, so that it will be impossible to enter another value by accident. Gilles Delmas -----Message d'origine----- De : epidata-list(a)lists.umanitoba.ca [mailto:epidata-list@lists.umanitoba.ca] Envoyé : mardi 13 décembre 2005 18:57 À : epidata-list(a)lists.umanitoba.ca Objet : [EpiData-list] Date variable I am having some difficulties playing around with a date variable (named v1, form dd/mm/yyyy). I wish to create a new variable with categories based upon different years within the original variable and I have tried copying the examples provided in the help section, but I'm not having any luck. Any direction would be greatly appreciated. Thanks, Kate

1 0

Howto: Group a date variable by calendar year
by epidata-list＠lists.umanitoba.ca 14 Dec '05

14 Dec '05

* Example pgm file to group a date variable V1 * created by: Jens Lauritsen, EpiData Association set show info=off generate 50 // generate 50 empty observations for testing define v1 <dd/mm/yyyy> define y #### y = 1900 + recnumber // could also be 1900 + _n v1 = dmy(1,7,y) * so now we have a date variable with dates from 1900 to 1950 * three different strategies to group. * Strategy 1: extract year from the date and recode to a string: define y1 #### define ys ________________________ y1 = year(v1) recode y1 to ys by 10 tab ys * Strategy 2: round the number into 10 year groups define y2 #### y2 = year(v1) y2 = trunc(y2/10)*10 // creates groups by 10 years tab y2 * If you use 5 instead of 10 you get 5 year groups * y2 = trunc(y2/5)*5 // creates groups by 5 years * strategy 3: split on specific dates: define y3 # let y3 = 0 if (v1 < dmy(1,10,1930) ) then y3 = 1 if (v1 >= dmy(1,10,1930)) and (v1 < dmy(1,10,1939) ) then y3 = 2 if (v1 >= dmy(1,10,1939)) and (v1 < dmy(1,10,1960) ) then y3 = 3 tab y3 * run the above to get the tabulations. ---------------------------------------------------------------------------------- Output: E.g. for strategy 1: No. % Cum % 1900 - 1909 9 18.00 18.00 1910 - 1919 10 20.00 38.00 1920 - 1929 10 20.00 58.00 1930 - 1939 10 20.00 78.00 1940 - 1949 10 20.00 98.00 1950 - 1959 1 2.00 100.00 Total 50 100% * strategy 2: No. % Cum % 1900 9 18.00 18.00 1910 10 20.00 38.00 1920 10 20.00 58.00 1930 10 20.00 78.00 1940 10 20.00 98.00 1950 1 2.00 100.00 Total 50 100% * strategy 3 No. % Cum % 1 30 60.00 60.00 2 9 18.00 78.00 3 11 22.00 100.00 Total 50 100% ---------------------------------------------------------------------------------- Regards Jens Lauritsen EpiData Association

1 0

Re: Double Entry Verification Mode Error, not virus
by epidata-list＠lists.umanitoba.ca 14 Dec '05

14 Dec '05

A new build (dec 13th) is almost ready which fixes some of the other issues of double entry mentioned earlier. Before releasing the new one we will find the cause of the error reported by Yali Zhang. If anyone else have issues of double entry please submit files to info @ epidata.dk Best Regards Jens Lauritsen EpiData Association

1 0

Date variable
by epidata-list＠lists.umanitoba.ca 13 Dec '05

13 Dec '05

I am having some difficulties playing around with a date variable (named v1, form dd/mm/yyyy). I wish to create a new variable with categories based upon different years within the original variable and I have tried copying the examples provided in the help section, but I'm not having any luck. Any direction would be greatly appreciated. Thanks, Kate

1 0

Double Entry Verification Mode Error, not virus
by epidata-list＠lists.umanitoba.ca 13 Dec '05

13 Dec '05

Hi, When I opened the T3_dbl.REC file for double entry, the system suggested that "DOUBLE ENTRY VERIFICATION MODE Error". I could open the T3_dbl.REC file, but I couldn't verify the entry. Why? How to solve it? There are some Chinese characters in the REC file. Thank you, Yali Zhang Department of Clinical Epidemiology Beijing Hui Long Guan Hospital Beijing Suicide Research and Prevention Center Beijing 10096 P.R.C Fax: 86-10-82951150 E-mail:zhang_bsrpc@hotmail.com zhangyali(a)crisis.org.cn _________________________________________________________________ 免费下载 MSN Explorer: http://explorer.msn.com/lccn/

1 0

Color of files during data entry and backup as check file command
by epidata-list＠lists.umanitoba.ca 12 Dec '05

12 Dec '05

In the help file users can find information on this: color data black yellow aqua color background white But not further information on how to use these check file commands. One example is: BEFORE FILE color data black yellow aqua color background white end Which will give yellow fields and aqua current entry fields. The background will be white and the colour of texts black. Backup as check file command The backup command documentation is incorrect in the help file. The help file says: AFTER FILE BACKUP F:\backup\distinationdirectory ZIP myzipfile.zip [DATE] END This should be: (to create a zip file with the date appended to the zip file name) AFTER FILE BACKUP F:\backup\distinationdirectory ZIP myzipfile [DATE] END It is always good practice to search the help file for a given word and if the examples are insufficient - then suggest to the list how it could be formulated. If users are not using the help system and this is due to faulty help system, then criticise the help system. But sometimes it appears that questions are asked without the user spending time on: 1. Looking in the help system 2. Searching old messages in the epidata-list on the topic 3. Looking in the further documentation supplied at the web page. http://www.epidata.dk/documentation.php We are now experimenting with solutions to translate analysis and create focused help. Users knowing of funding resources for translation please contact me at: info"at"epidata.dk (replace "at" with @) Best Regards Jens Lauritsen EpiData Association

1 0

RE: [EpiData-list] "date" fields
by epidata-list＠lists.umanitoba.ca 12 Dec '05

12 Dec '05

I don't think it is possible to modify the way EpiData 'understands' dates. Nevertheless, you cas add a check that refuses the date when it doesn't verify a certain condition: For example, if the date has to be at least 10 days before the date of entry, you will aff the following checkblock to the date field: DATE1 If DATE1 > today - 10 then Help "DATE1 has to be at least 10 days before today" goto DATE1 Clear DATE1 ENDIF END Line 1 (Help...) will display an error message each time the error condition is met. Line 2 & 3 (Goto / clear) will, as soon as the error message is akcnowledged, return to the field and erase what was previously entered, until a valid entry is entered (or nothing). ______________________________________________ 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é : vendredi 9 décembre 2005 13:32 À : epidata-list(a)lists.umanitoba.ca Objet : [EpiData-list] "date" fields Hello everybody I have made a .qes with several fields "date". If I want to enter data in such a field and type 1 then return, the field is automatically filled with 01/12/2005 (5/12/2005 if I type 5). Is it possible to avoid this automatic entry ? Thank you very much and have a nice day Beatrice

1 0

"date" fields
by epidata-list＠lists.umanitoba.ca 09 Dec '05

09 Dec '05

Hello everybody I have made a .qes with several fields "date". If I want to enter data in such a field and type 1 then return, the field is automatically filled with 01/12/2005 (5/12/2005 if I type 5). Is it possible to avoid this automatic entry ? Thank you very much and have a nice day Beatrice

1 0

colors of background, fields and letters
by epidata-list＠lists.umanitoba.ca 09 Dec '05

09 Dec '05

Hello everybody I have made a .qes, a .rec and a .chk files and I have to give the .rec and .chk files to a person who will enter the data. In "epidata" on my computer I have defined (file - options) color of background, fields, police and color of the letters.. Is it possible to keep these settings in these .chk and .rec file, so that the person will see the same colors as me without changing the settings of her "epidata" ? Thank you very much and have a nice day Beatrice

1 0

Transfering database from Excel to Epidata
by epidata-list＠lists.umanitoba.ca 07 Dec '05

07 Dec '05

Hello Is there anyway I can copy a database created in Exce or accessl to Epidata or do I have to manually re-create this in Epidata again. thank you. _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement

1 1

AW: [EpiData-list] Formatting and exporting data
by epidata-list＠lists.umanitoba.ca 06 Dec '05

06 Dec '05

Dear Jens I fully agree and support your approach to preserve maximum accuracy with the data at hand and the make the display somewhat flexible hopefully in a generic way or command specific. Additionally, the exact accuracy of the data should be preserved when exporting or saving in another data format. with best wishes marcel *********** Marcel Zwahlen, PhD Department of Social and Preventive Medicine University Berne Finkenhubelweg 11 CH-3012 Bern Switzerland phone ++41-31-631.3554 facsimile ++41-31-631.3520 email: zwahlen(a)ispm.unibe.ch http://www.ispm.unibe.ch/ -----Ursprüngliche Nachricht----- Von: epidata-list(a)lists.umanitoba.ca [mailto:epidata-list@lists.umanitoba.ca] Gesendet: Samstag, 3. Dezember 2005 11:45 An: epidata-list(a)lists.umanitoba.ca Betreff: [EpiData-list] Formatting and exporting data The question of how to format data by Susanne Widmar is a good one. Allow me to give a lengthy explanation since this is an issue in which we should agree on a uniform principle as well for import, export and use of data in EpiData Analysis. This relates to two aspects: 1. Accuracy of data - data types (binary, integer, real, double...) - we wish to replicate the precision of the collected data 2. How many decimals are shown on output from commands - we wish to see as much as needed for the interpretation - often less than aspect 1. In Stata the format is for some commands controlling the number of decimals, such as the CI command, whereas for other commands the display format is part of the command specification. The same "confusion" is now in EpiData Analysis where there is only partial consistency of showing and controlling formatting. In my view output formatting of the output should be decided by the command not by the data. In v1.1 build 54+ of EpiData Analysis (now available for testing) I have implemented for frequencies new options: freq v1 /D0 // would give percentages with no decimals freq v1 /D1 // would give percentages with one decimal For cross tables there are the settings for tables: TABLE PERCENT FORMAT COL P1() TABLE PERCENT FORMAT ROW P1{} TABLE PERCENT FORMAT TOTAL P1[] in which the user can define the number of decimals for the percentages For other commands (describe, means..) the display format of commands is either fixed or depending on the size of the estimates. User specification of output format will be implemented later. For import and export to Stata we could rewrite the procedures to work on datatype rather than format as it is now, if this is possible. We could then set all numerical variables to format %9.0g Another strategy could be to allow EpiData Analysis to save data in Stata format (which Bill Gould CEO of StataCorp has given permission to do). I suggest that users comment on the uniform strategy: a. All calculation is based on maximum accuracy with the data at hand b. Output formation should be part of each command. c. Data storage (type of variable) should be as strict as possible. Accomplishment of this is more important than speed of import and export. Regards Jens Lauritsen EpiData Association

1 0

Formatting and exporting data
by epidata-list＠lists.umanitoba.ca 05 Dec '05

05 Dec '05

Thanks Jens for your prompt and detailed response to my question about exporting numeric fields for use in Stata. While the fix you suggest in Stata (for var * : capture format X %9.0g) is simple for experienced Stata users, it's a bit painful as a general approach for new users. I'm definitely in favour of exporting according to type and sticking to %9.0g formatting, if this is possible. Cheers, Suzanna Suzanna Vidmar Research Fellow Clinical Epidemiology and Biostatistics Unit Royal Children's Hospital Flemington Rd Parkville Victoria 3052 telephone: +61 3 9345 6372 facsimile: +61 3 9345 6000

1 0

Re: Appending based on "dbf" files
by epidata-list＠lists.umanitoba.ca 03 Dec '05

03 Dec '05

A user reported problems with appending files which were exported from Excel as Dbase (dbf) I suggest you export as csv instead since some of the DBF files Excel creates are NOT of the correct format. An alternative could be to try different DBF formats (dbaseII DbaseIII DbaseIV) Some mails to the list regarding this problem were sent as HTML. The list will from today convert such mails to text format. But it is preferable that mails to the list are sent as plain text, since these mails are shorter - a nice gesture to persons with slow modem lines. In some mail programs, e.g. Thunderbird http://www.mozilla.com/thunderbird/ which is a freeware programme one can define which type of mails a certain receiver of mails can read. Jens Lauritsen EpiData Association

1 0

Re: Display format and Stata export
by epidata-list＠lists.umanitoba.ca 03 Dec '05

03 Dec '05

For NON-Stata users this mail is not relevant. Regarding the display format I forgot to show a solution: 1. export data to Stata format Either use EpiData and choose the version of Stata you prefer or use EpiC 2. Read the data into Stata 3. Set the display format as you desire: e.g. for a file myfile.rec to export to Stata and set numerical format %9.0g for all variables: epic export stata test\testdata\bromar.rec * replace Start Stata and issue the commands: use bromar.dta for var * : capture format X %9.0g ci ....... The reason for capture is that if you have a string variable there would be an error. Instead of the "for var *" you can use for var v1 v3 v13 etc and name the variables explicitly. In newer versions of Stata an alternative is foreach Kind regards Jens Lauritsen EpiData Association

1 0

Formatting and exporting data
by epidata-list＠lists.umanitoba.ca 03 Dec '05

03 Dec '05

The question of how to format data by Susanne Widmar is a good one. Allow me to give a lengthy explanation since this is an issue in which we should agree on a uniform principle as well for import, export and use of data in EpiData Analysis. This relates to two aspects: 1. Accuracy of data - data types (binary, integer, real, double...) - we wish to replicate the precision of the collected data 2. How many decimals are shown on output from commands - we wish to see as much as needed for the interpretation - often less than aspect 1. In Stata the format is for some commands controlling the number of decimals, such as the CI command, whereas for other commands the display format is part of the command specification. The same "confusion" is now in EpiData Analysis where there is only partial consistency of showing and controlling formatting. In my view output formatting of the output should be decided by the command not by the data. In v1.1 build 54+ of EpiData Analysis (now available for testing) I have implemented for frequencies new options: freq v1 /D0 // would give percentages with no decimals freq v1 /D1 // would give percentages with one decimal For cross tables there are the settings for tables: TABLE PERCENT FORMAT COL P1() TABLE PERCENT FORMAT ROW P1{} TABLE PERCENT FORMAT TOTAL P1[] in which the user can define the number of decimals for the percentages For other commands (describe, means..) the display format of commands is either fixed or depending on the size of the estimates. User specification of output format will be implemented later. For import and export to Stata we could rewrite the procedures to work on datatype rather than format as it is now, if this is possible. We could then set all numerical variables to format %9.0g Another strategy could be to allow EpiData Analysis to save data in Stata format (which Bill Gould CEO of StataCorp has given permission to do). I suggest that users comment on the uniform strategy: a. All calculation is based on maximum accuracy with the data at hand b. Output formation should be part of each command. c. Data storage (type of variable) should be as strict as possible. Accomplishment of this is more important than speed of import and export. Regards Jens Lauritsen EpiData Association

1 0

Display format
by epidata-list＠lists.umanitoba.ca 01 Dec '05

01 Dec '05

This is a question/comment for the folk at EpiData. Much of the data here is entered in EpiData and then analysed in Stata. I've noticed that in Stata the display format for a field is the same as the data entry format in EpiData. For example if the field "smoke" (0=no, 1=yes) has the field type set to # in EpiData, in Stata the display format is %1.0f. This can cause confusion with Stata commands that base the display format of their output on the display format of the field, e.g. the Stata command "ci". If I type the following into Stata: ci smoke, binomial The output I get looks like this: Variable | Obs Mean Std. Err. [95% Conf. Interval] -------------+--------------------------------------------------------------- sex | 44 0 0 0 0 because the mean, SE, and CI have been rounded to the nearest integer. Is it necessary for the output/exported format of fields to be the same as the data entry format? Can numeric fields be exported with a format of at least 9.0g? Cheers, Suzanna Suzanna Vidmar Research Fellow Clinical Epidemiology and Biostatistics Unit Royal Children's Hospital Flemington Rd Parkville Victoria 3052 telephone: +61 3 9345 6372 facsimile: +61 3 9345 6000

1 0