EpiData-list August 2006

epidata-list@lists.umanitoba.ca

1 participants
13 discussions

by epidata-list＠lists.umanitoba.ca

Hallo everyone, I am sending this note to anyone out there who can attach for me the copy of epidata data management complete manual. I am unable to download from the website. It is unfortunate for me since i did not have any backup in my computer. Kindly attach the copy for my reference. Be blessed in our continous understanding of epidata. Caleb Ouma Director, Dataworld Research Ltd. Kenya --------------------------------- Stay in the know. Pulse on the new Yahoo.com. Check it out.

17 years, 7 months

Appending

by epidata-list＠lists.umanitoba.ca

Dear Richard: You can do it in EpiData Entry the Epi Info way, that is two at a time. Alternatively, use the elegant EpiData Analysis solution: erase "abcde.rec" read "a.rec" append "b.rec" append "c.rec" append "d.rec" append "e.rec" save "abcde.rec" Regards, Hans Rieder I have several people entering data to a common structure at different sites. They email me the .rec files which I then combine into one file periodically. It seems as though I need to combine the files 2 at a time. Is it possible to combine them in one step? Are commands available such that a command file could do the task? Another option is to merge the files in SAS after converting the file 2 at a time, but that, too, would take several steps. Richard Herrell NIMH -- Hans L Rieder, MD, MPH Jetzikofenstr. 12 3038 Kirchlindach Switzerland Tel: +41 31 829 4577 Mob: +41 79 321 9122 Web: http://www.tbrieder.org

17 years, 8 months

RE: [EpiData-list] best text editor for complicated check files

by epidata-list＠lists.umanitoba.ca

In my experience you can write a longer check file with any editor also the internal editor, but the part above and beyond 64kb gets stripped of as soon as start using it in association with the QES file e.g. when you create a rec file or start entering data. Henriette Dr Henrica A.F.M. (Henriette) Jansen Epidemiologist, WHO Multi-country Study Violence against Women Department of Gender, Women and Health Tel direct: +41 22 791 3106 Fax direct: +41 22 791 1585 Mobile: +41 78 730 3035 E-mail: jansenh(a)who.int Website: http://www.who.int/gender/violence/multicountry/en/ -----Original Message----- From: epidata-list(a)lists.umanitoba.ca [mailto:epidata-list@lists.umanitoba.ca] Sent: 20 August 2006 16:58 To: epidata-list(a)lists.umanitoba.ca Subject: RE: [EpiData-list] best text editor for complicated check files The manual says that there is a 64kb limit to the size of a check file. Is this true if one uses an external editor or just the EpiData internal editor? --------------------------------- Get your email and more, right on the new Yahoo.com

17 years, 8 months

best text editor for complicated check files

by epidata-list＠lists.umanitoba.ca

I am looking for a recommendation for a text editor that support Epidata check file language. Suggestions? Karen Wang Earth Institute at Columbia University 61 Route 9W P.O. Box 1000 Palisades, NY 10964

17 years, 8 months

view deleted records in view data

by epidata-list＠lists.umanitoba.ca

Dear all, Thank you very much for the various valuable suggestions that I recently received to solve the issues around having both 01 and 1 accepted as legal value for a numerical field. I adopted a combination of strategies and think it is working fine now. Now I have an issue around deleted records. Because my QES and CHK files are so large I always have to work with related files for single (non-hierarchical) questionnaires. (As reported on this forum before, it is usually the 64k limit of the CHK file that forces me to split up my entry screens, rather than the 999 lines limitation for the QES). Because of this when a record needs to be deleted it will have to be done in both parts. Any error in this will result in orphaned bits of records so I insist the data entry supervisors watch out for this. Is there a fast way that the data entry supervisor can find the deleted files in a record? When I use "document" "view data" I do not see which records are deleted. I think I am probably overlooking something. Is there a way to make the deleted records quickly visible (without having to go through all of them one by one in the entry mode)? Thanks a lot for any suggestions. Best regards, Henriette Dr Henrica A.F.M. (Henriette) Jansen Epidemiologist, WHO Multi-country Study Violence against Women Department of Gender, Women and Health Tel direct: +41 22 791 3106 Fax direct: +41 22 791 1585 Mobile: +41 78 730 3035 E-mail: jansenh(a)who.int World Health Organization 20, avenue Appia CH-1211 Geneva 27 Tel: +41 22 791 2111 Fax: +41 22 791 3111 Visit WHO at: www.who.int

17 years, 8 months

RE: [EpiData-list] best text editor for complicated check files

by epidata-list＠lists.umanitoba.ca

I usually use EpiData itself, just by opening the CHK file under FILE, OPEN, and select the relevant file from all the files in the epidata working directory (make sure you select the correct file extension). For me the EpiData text editor works perfectly fine. I write all my check files from scratch and they are often very long and complicated. I do not use the check module and it has never occurred that comment lines were stripped away. Hope this is useful. Happy writing and best regards, Dr Henrica A.F.M. (Henriette) Jansen Epidemiologist, WHO Multi-country Study Violence against Women Department of Gender, Women and Health Tel direct: +41 22 791 3106 Fax direct: +41 22 791 1585 Mobile: +41 78 730 3035 E-mail: jansenh(a)who.int Website: http://www.who.int/gender/violence/multicountry/en/ -----Original Message----- From: epidata-list(a)lists.umanitoba.ca [mailto:epidata-list@lists.umanitoba.ca] Sent: 18 August 2006 21:36 To: epidata-list(a)lists.umanitoba.ca Subject: Re: [EpiData-list] best text editor for complicated check files I use Notepad for editing check files, although not necessarily creating them from scratch since it's easy to do from the check module. If there are repetitive checks in the file, I find it easier to use Notepad using cut-and-paste for complicated checks. One thing to note: if you like to have a lot of internal documentation in check files and you subsequently alter checks from the check module, comment lines in the .chk file get stripped away. epidata-list(a)lists.umanitoba.ca wrote: I am looking for a recommendation for a text editor that support Epidata check file language. Suggestions? Karen Wang Earth Institute at Columbia University 61 Route 9W P.O. Box 1000 Palisades, NY 10964 _______________________________________________ EpiData-list mailing list EpiData-list(a)lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list --------------------------------- Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta.

17 years, 8 months

Efficient strategy for complicated check files (external editor)

by epidata-list＠lists.umanitoba.ca

1. Re: best text editor for complicated check files The problem of "stripping comments" is that essentially only actual commands are read into the programme. When writing (or exporting) a rec file then only lines with commands are known to the programme. Therefore the order of using Epidata Entry and external editor is important. An efficient strategy would be: a. Create the qes and rec file b. Open the rec file for definition of checks in EpiData Entry. Here it is easy to get copy and paste for all of the field names. E.g. 1. I define that one field must be mustenter (regardless of I wish to have this). 2. When that field is active I press Ctrl+C (which copies the mustenter status to a buffer like clipboard) 3. Then I can quickly get a block for all fields into the check file by: 3a Moving to next field with "arrow down" with my right hand 3b pressing Ctrl+V with my left hand 4. Once point 3 is done for all fields I see if any fields have the same "comment legal / value label" if so I repeat point 1-3, but instead of the "mustenter" I define the labels in the first field and similarly copy to all the other fields of same label. 5. Then I close Epidata Entry and open the chk file in an external editor I prefer PFE, which has also a macro facility and is listed as a utility on the download page. But any external editor of the users preferance will work. 5a. I then change the special blocks in the editor, save the file and keep the editor open. 5b. During this I add a lot of comments to the chk file. 6. In EpiData Entry I open the rec file and after correcting possible errors the system is ready. So in short, use a strategy which minimises key strokes and manual editing, but also note that there are limitations with the built in possibilities. The worst errors to catch are those due to improper blocks. E.g. a comment legal without "end" or similar. Therefore it can be good practice to only solve the first error mentioned by EpIData Entry (point 6 above) and then try again, since the remaining errors might be a consequence of the first one. An idea for extension of the programme would be to have in "tools menu" a point : "Create raw chk file for experienced users". Regards Jens Lauritsen EpiData Association

17 years, 8 months

Date/ Date Range Selection

by epidata-list＠lists.umanitoba.ca

Dear Jamie, Thanks for the effort and time. I tried the TRUE FALSE option instead of Y and N , no luck. The examples you provided, were for European date format <dd/mm/yyyy> Actually the applications developed in EPI6 were running for many years. EPI6 liked <mm/dd/yyyy> format. So the data entered over many years had actually American <mm/dd/yyyy> format. I defined a new variable , AATDATE2 <dd/mm/yyyy> format, copied and converted American dates data to <dd/mm/yyyy>. Your last suggestion PQ= (ATTDATE2 >=DMY(1,1,2006) AND (ATTDATE2 <=DMY(30,3,2006) worked then. Epi Analysis does not feel comfortable with American date format. I am not professional programmer but still strongly feel that date/ date range selection should be simple and intuitive. Rather than posting fresh message, I request you to kindly help to solve following two queries also; 1.What is the EPI ANALYSIS equivalent of EPI6 command SET PROCESS=BOTH. EPI ANALYSIS processes only undeleted records. 2. While running long PGMs in EPI ANALYSIS, if no records are selected after a select condition, the programme aborts. The rest of the commands of the PGM are not processed. You might remember, EPI6 could run PGMs of any length, closing database, recoding, erasing and writing new .rec files easily. Jens and his Epidata Team have done a marvelous job of preserving the functionality of EPI6. May be few fine tuning are still required in this good effort. With regards Dr. Shavinder Singh Department of Community Medicine

17 years, 8 months

Date Range selection in Epi Analysis

by epidata-list＠lists.umanitoba.ca

Dear Jens, I am trying to use Epi Analysis for the Tuberculosis data analysis. I wrote following PGM. The date formats are American (mm/dd/yyyy). The ATTDATE variable is the date of starting of Anti-tuberculosis treatment. I want to select a date range of last 3 months to see the patients put on treatment in the last quarter. This selection should provide "y" value to the PG variable defined. The error messages received on the EpiAnalysis screen after running the command given, are given below; *TBQ.PGM (Updated on 15th August 2006) *Program gives the QUARTERLY status report of Tuberculosis of area. READ "d:\epi6\FGTRY\TB2000.REC" SET STATISTICS=OFF *Types the DATE RANGE of ATTDATE 3 months prior to beginning of present Quarter. *defines the time interval of 3 months prior to present Quarter. DEFINE PQ <Y> IF ATTDATE > date("01/01/2006","mdy") AND < date("03/30/2006",mdy") THEN LET PQ="Y" ELSE LET PQ="N" Error Massages in Epi Analysis; Syntax Error Script resulted in errors Operation aborted IF (ATTDATE > date("01/01/2006","mdy")) AND (ATTDATE < date("03/03/2006","mdy")) THEN LET PQ="Y" ELSE LET PQ="N" Error Massages in Epi Analysis; Data type mismatch IF ATTDATE date("01/01/2006","mdy") AND ATTDATE < date("03/30/2006","mdy") THEN LET PQ="Y" ELSE LET PQ="N" Error Massages in Epi Analysis; Then is missing Script resulted in errors Operation aborted SET STATISTICS=OFF *End of PGM. I tried these command combinations one by one but bot no luck. The date ranges selection has been a tough challenge. The F1 help section also has no clue. Kindly help. Dr. Shavinder Singh Department of Community Medicine

17 years, 8 months

Alignment Problem----Last Time

by epidata-list＠lists.umanitoba.ca

Dear Jens, Thanks so much for the time you took to respond to my concerns re alignment in ED. Now that I understand the technical problems you face in modifying the 'look' of the data entry screens, I will keep my mouth shut. I did not mean to give the impression in my original message that I will not continue to use ED. There are so many wonderful features you guys have developed on top of the EI features that you carried over that I will mess with the QES files to get the alignment I want. I have been using EI/ED for almost 20 years and have no intention of switching to anything else on earth, despite the fact that I have the resources to do so! There is simply nothing better, in my opinion, for epidemiologic studies and data. Thanks again Steve Blum $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ [EpiData-list] Aligning of fields and development priorities epidata-list at lists.umanitoba.ca epidata-list at lists.umanitoba.ca Fri Aug 4 16:27:42 CDT 2006 Previous message: [EpiData-list] Epidata alignment problem Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Steve has written about the: "Epidata alignment problem" The basic difference to remember from Epi Info v6 to EpiData and other windows based interface programmes is the change from character based to pixel based interface. The Epi Info screen V6 has 80 characters on aline which can either contain a space or some letter. Therefore what from simple logic could be phrased: (Quoted from Steve's mail:) "What EI does is remove the left bracket in field A and shift the REST OF THE LINE one space to the left. It then removes the right bracket from A and again shifts the REST OF THE LINE one space to the left. It then does exactly the same thing for field B. Everything would now be out of alignment with the next line, except that EI then adds two spaces IMMEDIATELY to the right of EACH field from which the brackets have been removed." is not simple in the Windows environment, because the width of a space is not easily attainable. The basic choice in developing EpiData could then be: a. We skip the rec file format altogether and create a new variant where alignments are measured in pixels instead of in characters. We develop a "drawing interface" where placements of fields are freely floatable. b. We maintain the rec file standard which has as a consequence that all sizes for the screen are measured in characters of variable width. The problem is that the header only allows for small numbers to describe placement of entry fields etc. c. We try to fiddle with a combination of calculations to estimate the length of "one space" and based on this use the REC file format as a basis of creating a "usually nice looking" entry screen. d. We add a new file type defining the exact positions of fields. e. We restrict choice of fonts to known types where alignment is possible. The point C is actually what we have done. The problem being that even with fixed size fonts the width of a space or a given letter is not very easy to calculate on a given screen. Many aspects of this is also bound to language. Some solutions are very good for one language, but not for other languages with special letters. EpiData Software is typically downloaded from nearly 100 countries every month, so to do development and accomplish only one or a few is not fair. Already basing all on the english language (and now website also in Spanish) is a restricted policy. E.g. obviously I would prefer that everything was written in my native language Danish, but only about 5 mio people speak that language. Users who have been along since 1999 will remember that in the beginning there were many problems of combinations of fields and texts which ended messed up/overlapped or hidden from the interface. So the current principle is a "parsimoneous" balance of different tests and principles creating exactly the alignment problems pointed out. So what are the solutions to the problem a. Someone find or develop very good algoritms which can in a standardised way replicate alignment properties and submit them to us. b. Persons who are very keen on this uses other software which is not tied to the limitations of the rec file format. There are plenty of commercial solutions to choose among. c. We find another solution. Option A: Anyone keen to experiment and spent time on this can find freeware tools at http://www.freepascal.org/ So the statement "If ED is indeed legacy EI then the face presented to the world should work properly." obviously is a very nice goal, but as mentioned not easy to attain. Focus is on the data entered NOT on the visual quality of the interface. The fact is that interface handling is a whole different story than: >But if there are resources for doing things like import/export, >pack, codebook, validate, consistency, compress, archive > which can all be handled by standard logic, and which tends not to be included in other software. What we have done with the EpiData development is to accomplish needs which we found possible and desirable within the time frame we had for this project. Data quality has the main driving priority - quality of alignment on screens has not. My suggestion is to add the issue "enhancements of data entry screen and design" to the development list for the plan 2006-2010. If someone are willing to find funding for this on top of the already planned activities it can be added, but otherwise it will not be added. Whether the patience of users of the software is sufficiently large for this approach or they decide on option B above is not up to me to decide. Kind regards Jens Lauritsen Initiator and Coordinator of development. EpiData Association Previous message: [EpiData-list] Epidata alignment problem Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the EpiData-list mailing list

17 years, 8 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 August 2006