- EpiData-list - University of Manitoba Mailing Lists

Retreiving a string
by epidata-list＠lists.umanitoba.ca 15 Apr '09

15 Apr '09

Epidata friends, I just spend almost the whole day trying to fix some typing errors. Nothing more than usual before starting some analysis. However It came to my attention that having just one key field maybe a lot misleading. Lets say that there a key id field called number in qes. v1 number ######### if the one who is typing types the worng number lets say 231022009 instead of 221022009 later this error may cause a lot of confusion and lead to other errors. The point is that this particular sort of error is hard to find and locate because this is the one field by which we should locate the record (the link to the CRF). Looking for the record by other fields is very fustrating unless the record has some very unusual data, such as age 99. How many records I would have with age 99?? Most likeli very few. One field that very often hleps is the patient intials, although it has very few letters, very unlikeli there is more than 3 or 4 in every thousand records with the same initials. Therefore I ask to you guys if there is a way in the chk file to retrieve from the name the initials of the full name. v1 number ######### v2 name: <A > v3 initials: <A > The objetictive is: v2 name: JENS LAURISTEN v3 initials: JL v2 name: PEDRO EMMANUEL AMERICANO DO BRASIL v3 initials PEADB Telling the typer to type this is an option, but Is it possible stick this magic in the chk file? I looked in the string functions from Epidata documentation but didnt find anything that could make a way around! Best regards? Abraço forte e que a força esteja com você, Pedro Emmanuel

1 1

Re: Double entry verification numeric fields
by epidata-list＠lists.umanitoba.ca 14 Apr '09

14 Apr '09

Epidata Friends, Yves gave a good work around on the id fields with leading zeros. I was suffering from the very same problem and did not stop to think on a work around. I did try this here with a data of mine and I have a another sugestion. It came to my attention that if the fieldnum has a autoserach command and the typer goes to edit a record already in the dataset then the fieldnum is deleted by the second chk command below. Perhaps a HELP command is more nice. FIELDNUM BEFORE ENTRY fieldnum=integer(fieldchar) goto nextvariable END autosearch list fieldnum END NEXTVARIABLE BEFORE ENTRY IF (fieldnum <> integer(fieldchar)) THEN HELP "PERHAPS THERE ARE SOME NON INTEGER CHARACTERS. CONSIDER REVISING!" ENDIF END This will call the attention of the typer and will not delete the data in the field if the record is to be edited. Best regards. Abraço forte e que a força esteja com você, Pedro Emmanuel

1 0

double entry verification : problem when entering numerical fields
by epidata-list＠lists.umanitoba.ca 13 Apr '09

13 Apr '09

Dear Epidata Team, First we have to thank you very much for the quality of your software. We intend to use EpiData for a double entry verification. Unfortunately, we have found a problem when entering numerical fields. If the keyboarder types 001 in a 3 digit numerical field, Epidata stores 1 (whitch is quite normal). But during the verification step, if they enter 001 again ... there is a message to remind them that there is a difference. Of course, the difference is between the stored value 1 et the first typed digit 0. This is a problem for us. In the framework of Clinical Trials, the operators have to enter exactly what is written on the CRF. A solution could be to define the field as a text one. But of course this allows to enter letters instead of digits, and that is not enough secure. We also tried to associate a numerical range (000-999) to the text 3 characters field (in a .CHK file). With this kind of control, typing a11 is denied, but typing 1a1 is allowed... Do you have an other solution or idea to solve this problem? In your forum, you answered to somebody that this problem will be solved in the next version of EpiData. Have you already an idea of the availability date of this version? Thank you very much in advance, Valérie Conte -- --------------------------------------------------------------- Valérie CONTE Directrice technique adjointe du CREDIM Chef de projet développement CREDIM Centre de Recherche Et Développement en Informatique Médicale ISPED Institut de Santé Publique, d'Epidémiologie et de Développement Casier 11 Université Victor Segalen Bordeaux 2 146 rue Leo Saignat 33076 Bordeaux Cedex Tel : 05.57.57.47.60 Fax : 05.57.57.45.41 --------------------------------------------------------------- Mel : mailto:Valerie.Conte@isped.u-bordeaux2.fr Web : http://www.isped.u-bordeaux2.fr ---------------------------------------------------------------

1 4

Error in exporting to Stata
by epidata-list＠lists.umanitoba.ca 31 Mar '09

31 Mar '09

Epidata friends, Im using epidata entry and after almost a 1000 records Im trying to export the data to Stata to start some initial analysis. However, when exporting to Stata format a warning comes and no data are exported. The warning is... Invalid data in record #889, filed sintocol, Export concluded. I tryed to export ot other formats such as dbase an sas and spss... the problem only happans when exporting to stata format! I opened epidataentry and checked the register 889 and it did not seemed to have anything wrong wiht it. Later I tryed to delete this register and the error still coming! Any sugestions? -- Abraço forte e que a força esteja com você, Pedro Emmanuel

1 0

fixing the p50 problem
by epidata-list＠lists.umanitoba.ca 30 Mar '09

30 Mar '09

Bono Branger gave an example of an existing problem with Epidata Analysis. The problem relates to the median (P50) for life-tables. I am aware of the "non-fixing" of the problem. Obviously we will fix this problem, but you must also be aware of the nature of the project. We are NOT a company, we do not get any license fees from the users. We are fixing problems within certain timelimits and priorities. Just now - as I have informed on this list - the priority is to rewrite some core modules for long term sustainability. We will get to the p50 problem. Reproducible errors should be reported to the bug tracking system - for which you find the address on the website epidata.dk (Mantis system). Anyone not satisfied with the principles can at any time choose not to use the software and buy (expensive) commercial software. regards Jens Lauritsen EpiData Association

1 0

Lifetable - Error on P50 calculation
by epidata-list＠lists.umanitoba.ca 29 Mar '09

29 Mar '09

Hello, I am very disappointed about error for the calculation of p50 in lifetable. Probably, Ill stop the use of this command (I had very hoped in this program..). I join an example with 3 errors. I can address the file. Thank you. Bernard BRANGER, Nantes, France . lifetable arret durall /p50 /by=codemat /t /noci Life Table: ARRET by codemat Total N Cases n Expected Cases Time Minimum Maximum Sum time Hazard Ratio Time S=0.50 Time Diff. 1 19 16 11.56 1 29 249 Ref. 10.00 Ref. 2 10 6 5.97 1 29 127 1.07 11.00 1.00 3 10 5 6.81 1 28 147 0.02 15.00 5.00 4 10 6 3.04 1 14 77 842818.30 8.00 -2.00 5 22 14 16.74 1 29 344 0.09 14.00 4.00 6 18 13 13.09 4 27 284 0.91 26.00 16.00 8 14 13 7.27 1 29 160 87399.95 23.00 13.00 9 18 15 10.93 0 29 239 223.32 12.00 2.00 10 20 17 15.50 1 28 333 4.12 30.00 20.00 11 7 6 3.22 1 22 72 235936.51 11.00 1.00 12 21 11 14.84 1 29 312 0.02 18.00 8.00 13 20 15 13.92 1 28 303 3.09 13.00 3.00 14 28 15 20.54 3 29 437 0.02 23.00 13.00 15 20 8 16.57 0 29 344 0.00 27.00 17.00 Outcome: ARRET = 1 Log Rank test of equality of survivor function: Chi2(13)= 21.092 P= 0.0711 LR test of homogeneity among groups Chi2(13)= 17.547 p= 0.1755 Interval NAt risk Deaths Lost Survival 1 1-2 19 1 0 0.95 2-3 18 2 0 0.84 4-5 16 1 0 0.79 6-7 15 2 0 0.68 8-9 13 1 0 0.63 9-10 12 1 0 0.58 10-11 11 2 0 0.47 13-14 9 1 0 0.42 14-15 8 1 0 0.37 16-17 7 1 0 0.32 19-20 6 1 0 0.26 21-22 5 1 0 0.21 25-26 4 1 0 0.16 27-28 3 0 1 0.16 28-29 2 0 2 0.16 2 1-2 10 1 0 0.90 4-5 9 1 0 0.80 8-9 8 2 0 0.60 9-10 6 0 1 0.60 11-12 5 1 0 0.48 15-16 4 1 1 0.36 28-29 2 0 2 0.36 3 1-2 10 2 0 0.80 7-8 8 1 0 0.70 9-10 7 0 1 0.70 13-14 6 1 0 0.58 15-16 5 1 0 0.47 24-25 4 0 1 0.47 25-26 3 0 2 0.47 27-28 1 0 1 0.47 4 1-2 10 1 0 0.90 5-6 9 1 1 0.80 6-7 7 1 0 0.69 8-9 6 2 0 0.46 9-10 4 1 1 0.34 13-14 2 0 2 0.34 5 1-2 22 1 0 0.95 3-4 21 4 0 0.77 5-6 17 1 0 0.73 8-9 16 1 0 0.68 10-11 15 2 1 0.59 11-12 12 1 0 0.54 14-15 11 1 0 0.49 16-17 10 1 0 0.44 25-26 9 1 0 0.39 27-28 8 0 2 0.39 28-29 6 1 5 0.33 6 4-5 18 1 0 0.94 5-6 17 1 0 0.89 6-7 16 1 0 0.83 7-8 15 1 0 0.78 8-9 14 1 0 0.72 11-12 13 1 0 0.67 12-13 12 1 0 0.61 13-14 11 1 0 0.56 15-16 10 1 0 0.50 16-17 9 1 0 0.44 17-18 8 1 0 0.39 19-20 7 1 0 0.33 21-22 6 1 0 0.28 26-27 5 0 5 0.28 8 1-2 14 1 0 0.93 3-4 13 2 0 0.79 7-8 11 2 0 0.64 8-9 9 2 0 0.50 9-10 7 1 0 0.43 10-11 6 1 0 0.36 15-16 5 1 0 0.29 18-19 4 2 0 0.14 25-26 2 1 0 0.07 28-29 1 0 1 0.07 9 0-1 18 1 0 0.94 4-5 17 1 1 0.89 6-7 15 2 0 0.77 7-8 13 1 0 0.71 9-10 12 2 0 0.59 12-13 10 2 0 0.47 14-15 8 2 0 0.36 16-17 6 1 0 0.30 20-21 5 1 0 0.24 25-26 4 2 0 0.12 28-29 2 0 2 0.12 10 1-2 20 1 0 0.95 3-4 19 1 0 0.90 5-6 18 1 0 0.85 7-8 17 1 0 0.80 8-9 16 2 0 0.70 10-11 14 1 0 0.65 14-15 13 1 0 0.60 15-16 12 1 0 0.55 18-19 11 2 0 0.45 22-23 9 1 0 0.40 23-24 8 2 0 0.30 25-26 6 1 0 0.25 26-27 5 2 0 0.15 27-28 3 0 3 0.15 11 1-2 7 1 0 0.86 4-5 6 1 0 0.71 10-11 5 1 1 0.57 11-12 3 1 0 0.38 15-16 2 1 0 0.19 21-22 1 1 0 0.00 12 1-2 21 1 0 0.95 3-4 20 1 0 0.90 4-5 19 0 1 0.90 7-8 18 2 0 0.80 9-10 16 2 1 0.70 10-11 13 1 0 0.65 13-14 12 0 1 0.65 14-15 11 0 1 0.65 16-17 10 2 0 0.52 17-18 8 0 1 0.52 18-19 7 1 0 0.45 20-21 6 1 0 0.37 27-28 5 0 1 0.37 28-29 4 0 4 0.37 13 1-2 20 1 0 0.95 4-5 19 0 1 0.95 7-8 18 1 0 0.90 9-10 17 3 0 0.74 12-13 14 3 0 0.58 13-14 11 3 0 0.42 15-16 8 1 0 0.37 16-17 7 1 0 0.32 25-26 6 1 0 0.26 26-27 5 1 1 0.21 27-28 3 0 3 0.21 14 3-4 28 2 0 0.93 5-6 26 0 1 0.93 6-7 25 1 0 0.89 8-9 24 1 2 0.85 9-10 21 1 2 0.81 10-11 18 0 1 0.81 13-14 17 0 3 0.81 14-15 14 0 1 0.81 15-16 13 1 0 0.75 16-17 12 1 0 0.69 19-20 11 0 1 0.69 21-22 10 2 0 0.55 23-24 8 1 0 0.48 24-25 7 1 0 0.41 27-28 6 1 0 0.34 28-29 5 3 2 0.14 15 0-1 20 1 0 0.95 3-4 19 1 0 0.90 5-6 18 0 1 0.90 7-8 17 0 1 0.90 11-12 16 0 1 0.90 13-14 15 1 0 0.84 14-15 14 0 3 0.84 15-16 11 2 0 0.69 19-20 9 1 0 0.61 21-22 8 1 0 0.53 26-27 7 0 1 0.53 27-28 6 1 0 0.45 28-29 5 0 5 0.45 _____ Jutilise la version gratuite de SPAMfighter pour utilisateurs privés. Jusquà présent SPAMfighter a bloqué 568 courriels spam. Nous avons en ce moment 6 millions dutilisateurs de par le monde entier. Les utlisateurs payants nont pas ce message. Vous pouvez télécharger la version gratuite <http://www.spamfighter.com/lfr> _____ Jutilise la version gratuite de SPAMfighter pour utilisateurs privés. Jusquà présent SPAMfighter a bloqué 594 courriels spam. Nous avons en ce moment 6 millions dutilisateurs de par le monde entier. Les utlisateurs payants nont pas ce message. Vous pouvez télécharger la version gratuite <http://www.spamfighter.com/lfr>

1 0

testing of quick guide for SPC graphs
by epidata-list＠lists.umanitoba.ca 22 Mar '09

22 Mar '09

Dear All As part of telling of the most recent implementation of SPC Control graphs while attending a quality assurance conference/forum in Berlin (http://internationalforum.bmj.com/) last week I produced a "Statistical Process Control Graphs in 5 minutes" - a link is placed near the top on epidata.dk. Please comment whether you find the text appropritate. (e.g. whether it should be 10 rather than 5 minutes). See front page of EpiData or this direct link: http://www.epidata.dk/downloads/spc5min_epidata.pdf regards Jens Lauritsen EpiData Association

1 0

recoding numbers....
by epidata-list＠lists.umanitoba.ca 13 Mar '09

13 Mar '09

Hello all, Im facing a little problem which so far I could not find a work around. Any sugestions would be welcome. I have tow datasets which come from different sources... I intended to join them side-by-side with epidata entry to keep on going wiht the data update. I know that the second one would update some stuff in the firts one, at least for the majority of the observations. Both of the have a unique identifier which is a variable called num. However in the first set num is like this... 133.01.2007 244.01.2007 while in the second one num is like this... 2007.01.133 2007.01.244 For any software these would be different numbers but given that I know that 2007 is the yaer and 1 is january and 244 or 133 is the sequence within the month I know that the second dataset have num in the inverse order. Concatenating the datasets like this would be just as append because no observatiosn would match. I tought in recode the numbers but this would be same as digitizing all again. Nay sugestions? -- Abraço forte e que a força esteja com você, Pedro Emmanuel

1 1

v2.2 of EpiData Analysis - released
by epidata-list＠lists.umanitoba.ca 12 Mar '09

12 Mar '09

Version 2.2 has been released for public downloads today. You can get it from http://www.epidata.dk/downloads.php The file is provided as a setup exe file, but also as already installed, where all files are contained in a zip file. Since last public release in november 2008 quite many aspects have been improved or adapted. In particular the whole SPC (Statistical Process Control) graph system has been extended with more options and more efficient layout. Also a grid for creating SPC graphs from scratch has been implemented. - is available from the graph menu. Some set commands have changed, such that users can be forced to update any specified ini file that was created with the former version. An extension is the possibility for the user to create preference options for all commands, example: set option tables = "/t /r /c" would define that all tables done with the command "tables" will be added the options /t /r and /c Just today an error with stratified tables and small sample sizes was reported - the error is now fixed. The problem was that some strata would be combined incorrectly. Analysis done previously should be repeated with the new version and proper control. Please report any remaining problem. To see all changes go to the file: http://www.epidata.dk/analysisversioninfo.htm Commands are all as previously documented in the command reference, which will open when you press F1. Please notice that the release of this depends on donated funding, as documented on the page: http://www.epidata.dk/funding.htm Users should update to this version of analysis, since some of the bugs removed could affect results. The development continues with further online documentation and teaching materials as well as core module restructuring, such as announced on the list recently. regards Jens Lauritsen

1 1

SPSS v17 export problem
by epidata-list＠lists.umanitoba.ca 12 Mar '09

12 Mar '09

Hello. I have recently "upgraded" to SPSS v17. My exports from EpiData to SPSS format no longer work. The error messages I get in the SPSS syntax editor are: 14 DATA LIST Unrecognized text appears on the DATA LIST command where a variable name was expected. Text: TO 69 VARIABLE LABELS This command is not permitted before the beginning of file definition commands. 137 execute This command is not valid before a working file has been defined. Can someone suggest a resolution? Thank-you kindly. __________________________ Stephen Drew Health Data Analyst Region of Waterloo Public Health

1 1