- EpiData-list - University of Manitoba Mailing Lists

autosearch and document
by epidata-list＠lists.umanitoba.ca 09 Mar '05

09 Mar '05

Dear Dr. Lauritsen, When I used "autosearch" command in the check file in order to prevent creation of duplicate records, I found that the "type comment on" command in the same field became disabled, and the double entry verfication is also disabled. Why ? And How to solve it? Sometimes in "View Data", "List Data" and "Codebook", the values of numeric fields were disappeard. I don't know why and have not discoverd any regluar rule. Thank you very much. Best Regards, Yali Zhang _________________________________________________________________ 免费下载 MSN Explorer: http://explorer.msn.com/lccn

1 0

automatic date
by epidata-list＠lists.umanitoba.ca 07 Mar '05

07 Mar '05

Has anyone noticed the following with the automatic date field type <Today-dmy>? When entering the first record for the day, this field does not display today's date but displays the date when the last record was entered. Once a record has been entered and saved, this field is updated to the current date. When entering a new record I expected the automatic date to display today's date regardless of whether or not a record has been entered today. Do you have any idea why this is not the case? Thanks, Suzanna Suzanna Vidmar Senior Research Assistant Clinical Epidemiology and Biostatistics Unit Royal Children's Hospital Flemington Road Parkville Victoria 3052 telephone: +61 3 9345 6372 facsimile: +61 3 9345 6000

1 1

Re: EpiData-list Digest, Vol 17, Issue 5 (Out of the office)
by epidata-list＠lists.umanitoba.ca 04 Mar '05

04 Mar '05

I will be out of the office from Friday March 4th through Friday March 11th, 2005. I will reply to your email as soon as possible. If you need immediate assistance please call Bennie Daughtry at (803) 545-4471.

1 0

Initial test of Analysis build 18 - TABLES
by epidata-list＠lists.umanitoba.ca 04 Mar '05

04 Mar '05

As I noticed the table was not implemented correctly in build 18, but should be correct (for the data I tested) in build 19. Build 19 was made available early today/late last night depending on where you live. The intention was to always have as pointed out by Jamie Hockin: TABLES outcomevar exposurevar stratifyvar1 stratifyvar2 stratifyvar3 Please review the adapted commands and functions list. You can search on (ctrl+f) "table epi" and in options for search mark out "helpfie" and the file will open in the output window. (the file has a formatting error now - but contents are there) set table labels=on[off] (Use comment legal "value labels" as text descriptors in tables) set table values=on[off] (show category values in tables) set table epi=on[off] (With on: tables are inverted (highest values in top left corner) set table percents=on[off] set table percents format="P1()"[off] (Content percents coloumn) 1: decimals () before after. e.g. "P2 %" set table percents header="%" (Contents of column header for percents) set table RR=on[off] show Risk Ratio in 2x2 tables set table OR=on[off] show Odds Ratios in 2x2 tables to control statistics output: set table statistics="OR RR EXACT CHI" eliminate the ones you do not want. e.g. set table statistics="CHI" regards Jens Lauritsen EpiData Association

1 0

Initial test of Analysis build 18 - TABLES
by epidata-list＠lists.umanitoba.ca 03 Mar '05

03 Mar '05

My favourite data set for TABLES is RELY.REC as it will eventually be a good test of MATCH. For this data, the 'inverted' table should read =========> tables rely case CASE RELY │ + - │ Total ───────────┼─────────────┼────── + │ 11 13 │ 24 - │ 3 29 │ 32 ───────────┼─────────────┼────── Total │ 14 42 │ 56 (from Epi6) EpiData Analysis gives me CASE RELY Y % N % Total % Y 11 (45.8) 3 (9.4) 14 (25.0) Y 13 (54.2) 29 (90.6) 42 (75.0) N 24 (100.0) 32 (100.0) 56 (100.0) Two problems: 1) The data are not inverted. However, the results are correct (OR, RR, etc) 2) Labelling for rows is not correct "N" row labelled "Y", "Total" row labelled "N" Percentages here are appropriate for Case-control study, but would not be of interest for Cohort study. Of course, the option to remove them is with the user. Turning on/off of OR and RR behaves as expected. if I turn off both OR and RR, I get a correct table: RELY CASE N Y Total N 29 13 42 Y 3 11 14 Total 32 24 56 So the problem is that with OR=on or RR=on, the rows and columns are switched, but the table has not been rotated to put CASE on top. I think that it will be more consistent to always put the first TABLES variable as the column header, or if the preferred practice for tables is to put the first variable as rows then we could accept 2x2 tables with the outcome in rows. The problem is that, looking at the output and the command, I'm confused about how I construct the command to get what I want. We have to enforce TABLES outcomevar exposurevar if we want RR to be calculated correctly. Jamie Hockin

1 0

New build of analysis (build 19)
by epidata-list＠lists.umanitoba.ca 03 Mar '05

03 Mar '05

A new build of analysis was just put out on www.epidata.dk/testing.php The table command was in a mess in build 18 from yesterday due to various technical problems (Apologies for the inconvenience.) Estimates for at least one data file are the same as with Stata 7 (Odds Ratios and RR). Also it has been defined such that the first variable on the tables command (tab) will always go across, the second down and any further will be used for stratification. The "set parameters" have been more standardised. Try "set" to see which ones are currently defined and their names. e.g. for tables: set table statistics="OR RR CHI EXACT" would include all whereas: set table statistics="OR CHI" would only include odds ratios, chi square measures The promised solving of reading unknown fields as character fields will be part of coming builds - not this one. regards Jens Lauritsen EpiData Association.

1 0

[Fwd: Short dates and menus in HTML]
by epidata-list＠lists.umanitoba.ca 02 Mar '05

02 Mar '05

This is good, Jens. Epi6 was so forgiving because it treated any unknown field as a string - a nice backwards compatibility feature as it turns out. Unfortunately, this went along with Epi6 producing invalid files from time to time. A good strategy for menus to do different analyses might be to create some .pgm files and simplify the HTML coding to just launch the appropriate .pgm. This would provide better documentation of complicated scripts. Once you get used to the syntax, HTML menus need not be any more complicated than EPI6 .mnu files. Outside of Analysis and with the right javascript tools & code fragments a lot is possible. Jamie Hockin

1 0

out of office reply
by epidata-list＠lists.umanitoba.ca 02 Mar '05

02 Mar '05

I will be out of office and not be checking my emails until March 4, 2005. marcel zwahlen

1 0

Svar: RE : [EpiData-list] Re: New analysis build (18) ready for testing(error reading date variables)
by epidata-list＠lists.umanitoba.ca 02 Mar '05

02 Mar '05

In the next build we will adopt the strategy that old formats such as <dd/mm>, <dd/mm/yy> or phone number fields will be read into analysis as strings. The user can then convert to date or numerical variables using functions in analysis. Jens Lauritsen EpiData Association.

1 0

RE : [EpiData-list] Re: New analysis build (18) ready for testing(error reading date variables)
by epidata-list＠lists.umanitoba.ca 02 Mar '05

02 Mar '05

Thanks Jens When you export oswego.rec to STATA using EpiData, you get a string variable in STATA that you have to work with, but no error I agree that this rather strange format with only mont hand day is not fantastic. Anyway, quite many people did use it because for brief studies it is OK The idea of developping a kind of conversion procedure makes sense, even if some recoding is needed after conversion like in STATA The crucial point is the ability to transfer old files to EpiData whether or not is absolutely "ready to use" Regards Robert -----Message d'origine----- De : epidata-list-bounces(a)lists.umanitoba.ca [mailto:epidata-list-bounces@lists.umanitoba.ca] De la part de epidata-list(a)lists.umanitoba.ca Envoyé : mercredi 2 mars 2005 13:45 À : epidata-list(a)lists.umanitoba.ca Objet : [EpiData-list] Re: New analysis build (18) ready for testing(error reading date variables) Robert wrote: "The last build does not work : cannot read rec file OSWEGO for example Any idea ??" This is a marvellous example of why end-users should participate in testing. It turns out that the version of OSWEGO.REC I am testing on has been updated with EpiData. When I do so all date fields are changed to full length dates including year. So I did not see the error. I can see now that with the original OSWEGO.REC I get the same error as indicated by Robert. Lesson learned: Make sure that testing includes types of error that you do not want to happen. In practice. We will from now on include a test of how analysis treats files with all the variable formats of Epi6. Even the ones we "abandoned", such as 2 digit year or dates without year. Rules from EpiData for these types of dates will be included in next build. (Extending to 4 digit years and adding current year to fields without year) regards Jens Lauritsen EpiData Association _______________________________________________ EpiData-list mailing list EpiData-list(a)lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list

1 0