EpiData-list December 2005

epidata-list@lists.umanitoba.ca

1 participants
20 discussions

by epidata-list＠lists.umanitoba.ca

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

18 years, 4 months

"date" fields

by epidata-list＠lists.umanitoba.ca

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

18 years, 4 months

colors of background, fields and letters

by epidata-list＠lists.umanitoba.ca

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

18 years, 4 months

Transfering database from Excel to Epidata

by epidata-list＠lists.umanitoba.ca

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

18 years, 4 months

AW: [EpiData-list] Formatting and exporting data

by epidata-list＠lists.umanitoba.ca

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

18 years, 4 months

Formatting and exporting data

by epidata-list＠lists.umanitoba.ca

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

18 years, 5 months

Re: Appending based on "dbf" files

by epidata-list＠lists.umanitoba.ca

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

18 years, 5 months

Re: Display format and Stata export

by epidata-list＠lists.umanitoba.ca

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

18 years, 5 months

Formatting and exporting data

by epidata-list＠lists.umanitoba.ca

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

18 years, 5 months

Display format

by epidata-list＠lists.umanitoba.ca

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

18 years, 5 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

EpiData-list December 2005