- EpiData-list - University of Manitoba Mailing Lists

RE: linux and Epidata
by epidata-list＠lists.umanitoba.ca 31 May '06

31 May '06

At the moment EpiData has been testet on SuSE Linus 9.3 and Fedora Core 4. If you are running KDE or Gnome on Conectiva you should be able to run EpiData using the newest version of wine. Probably you will be able to run Wine(EpiData) in other environments as well, but it has yet not been testet. The Wine HQ homepage: http://www.winehq.com/ The download page: http://www.winehq.com/site/download After installing wine, install EpiData. If wine doesn't start when you try opening EpiData, open the terminal/konsole and type: wine EpiData.exe (in the appropriate folder) Known problems using EpiData in wine: EpiData will sometimes refuse to close Errors ind the chk-file can resolut in "strange" behaviour

1 0

Sumfreq / Sumtables
by epidata-list＠lists.umanitoba.ca 29 May '06

29 May '06

Has anyone an idea on how to replace Sumfreq (or sumtables) with Epidata analysis? Thanks! Gilles / Paris

1 0

linux and Epidata
by epidata-list＠lists.umanitoba.ca 25 May '06

25 May '06

I am hard user of the Epidata there is a long time and I am very satisfied with the soft. Now, I wish install Epidata in operacional system Linux (Conectiva a Brazilian version) a lot similar to Mandrake. How to do that ? Epi Analysis is already in Linux working perfectly. Best regards Claudio Teixeira e-mail cteixeira(a)fmc.br ou cteixeira(a)terra.com.br Home page da Fac. de Medicina de Campos http://www.fmc.br 2006-05-25

1 0

Problems with double entry validation - warning
by epidata-list＠lists.umanitoba.ca 23 May '06

23 May '06

During the most recent week we have seen a few problems with double-entry validation. Obiously double entry makes no sense if assumed validation is done, but in practice no validation is taking place. The three situations are: 1. Do NOT use double entry if the command AUTOSEARCH is used in the field which is used for the identification of records. 2. If the field for double entry is computed based on some other fields and that computed field only occurs after entry of a number of fields, then the validation is also problematic. 3. In a relate situation. When creating the file for double entry only the top level entries are created automatically. Not for the lower level files. For the situation number two (Created link field) it is quite obvious that the programme cannot validate entry of records before the "linking field" is created. There is no way to find out with which record to compare values in the other file before the "linking" information is created. For situation one (AUTOSEARCH) the situation is that the "pointer" to a given record might change in the autosearch field therefore creating a complicated "link" situation that changes during a given entry. For the development it is essential that such problems are reported. Following detection they are added to a list of known problems to be solved. It is good practice to verify functionality of any software before doing a lot of work in particular with complicated data structures or situations. Jens Lauritsen EpiData Association

1 0

Double Entry and Autosearch: Danger!
by epidata-list＠lists.umanitoba.ca 22 May '06

22 May '06

After having stuggled with the problem that double entry did not work properly we found a solution to the following problem: When we tried to double enter data using the "match records by fields" option, EpiData did only check the data of the first record entered. Starting with a second record we only accidentally noticed that EpiData did actually not check the data. We tried different things to overcome this problem but EpiData behaved erratic if we went back to an already entered record. This behavior is dangerous because you might think that EpiData checks your data during double entry (all the more if you encountered an entry error in the first record). The solution: If the .REC file to enter data in double check mode uses a .CHK-file, don't use "AUTOSEARCH" (at least not for the field/variable that is used in the "match records by fields" option)! You may use "KEY UNIQUE", instead. Current EpiData version: 3.1 (120306) Dirk ************************************************* Dr. Dirk Enzmann Institute of Criminal Sciences Dept. of Criminology Edmund-Siemers-Allee 1 D-20146 Hamburg Germany phone: +49-(0)40-42838.7498 (office) +49-(0)40-42838.4591 (Billon) fax: +49-(0)40-42838.2344 email: dirk.enzmann(a)uni-hamburg.de www: http://www2.jura.uni-hamburg.de/instkrim/kriminologie/Mitarbeiter/Enzmann/E… *************************************************

1 0

Can a certain feature be implemented or extended in EpiData ?
by epidata-list＠lists.umanitoba.ca 18 May '06

18 May '06

Dirk created a very precise description of the problem of the 64k size limitation of a .not file. and asks : > Question: Is there any other solution? Is it possible to improve > EpiData such that longer .not-files are possible? Since we are in control of the software in principle anything can be extended or adapted. As previously announced a conversion plan of EpiData Entry and Analysis to opensource has been made and we are looking for financing sources for the plan. The overwhelming number of downloads, increasing number of scientific publications, field reports and courses made with EpiData Software indicates the relevance of extending and securing the software. The total cost of the reprogramming of the entry module and adaptation of analysis amounts to the price of less than 250 one year licenses for SPSS or a similar number of single user permanent licenses for Stata. (300.000 Euro). In the rewriting all known problems and limitations will be considered, including the size problem of .not files. And I am sure many of them will be fixed. Anyone having knowledge of foundations, larger projects or other sources for funding should contact me directly for further information. Once something starts coming in I will create a "barometer" of achieved funding on the website. Kind regards Jens Lauritsen EpiData Association. "J L at epidata.dk " (remove spaces)

1 0

RE: [EpiData-list] size of EpiData note files
by epidata-list＠lists.umanitoba.ca 18 May '06

18 May '06

The same problem occurs with .chk files that exceed a certain size. Currently I need to split .qes and .chk files in several parts and connect them with RELATE. For our long questionnaires, this is only in some cases due to the 999 lines limitation for the .qes file, but even if the questionnaire fits 999 lines, I need to split the .qes and .chk files because of the fact that the .chk files get truncated at their maximum size. Is it possible to improve EpiData on this point? EpiData is such a useful program for our surveys in the field. It would be really be a great improvement if this limitation was not there! Thanks a lot! 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: 17 May 2006 20:06 To: epidata-list(a)lists.umanitoba.ca Subject: [EpiData-list] size of EpiData note files Unfortunately, if the size of the .not-files into which user-notes and EpiData generated notes are written exceeds about 64k, the coders can't enter further comments (although notes generated "automatically" via .chk-file commands will still be added). One solution to this problem is to close EpiData and to rename the .not-file. A new start of EpiData will then generate a new .not-file automatically. However, this solution is error prone, risky, and tedious: - you have to keep track of the size of the .not-files so that the coders can always enter their comments; - you may not overwrite renamed .not-files accidentally; - you have take care to collect/archive *all* renamed .not-files; - the solution is difficult to implement if the coders work independly and should not change files directly by themselves. Question: Is there any other solution? Is it possible to improve EpiData such that longer .not-files are possible? Current EpiData version: 3.1 (120306) [Sorry for any inconvience: I send this mail a second time because the first went not through - my email-address has changed and I was not recognized as a "member" of the list] Dirk -- ************************************************* Dr. Dirk Enzmann Institute of Criminal Sciences Dept. of Criminology Edmund-Siemers-Allee 1 D-20146 Hamburg Germany phone: +49-(0)40-42838.7498 (office) +49-(0)40-42838.4591 (Billon) fax: +49-(0)40-42838.2344 email: dirk.enzmann(a)uni-hamburg.de www: http://www2.jura.uni-hamburg.de/instkrim/kriminologie/Mitarbeiter/Enzman n/Enzmann.html *************************************************

1 0

size of EpiData note files
by epidata-list＠lists.umanitoba.ca 17 May '06

17 May '06

Unfortunately, if the size of the .not-files into which user-notes and EpiData generated notes are written exceeds about 64k, the coders can't enter further comments (although notes generated "automatically" via .chk-file commands will still be added). One solution to this problem is to close EpiData and to rename the .not-file. A new start of EpiData will then generate a new .not-file automatically. However, this solution is error prone, risky, and tedious: - you have to keep track of the size of the .not-files so that the coders can always enter their comments; - you may not overwrite renamed .not-files accidentally; - you have take care to collect/archive *all* renamed .not-files; - the solution is difficult to implement if the coders work independly and should not change files directly by themselves. Question: Is there any other solution? Is it possible to improve EpiData such that longer .not-files are possible? Current EpiData version: 3.1 (120306) [Sorry for any inconvience: I send this mail a second time because the first went not through - my email-address has changed and I was not recognized as a "member" of the list] Dirk -- ************************************************* Dr. Dirk Enzmann Institute of Criminal Sciences Dept. of Criminology Edmund-Siemers-Allee 1 D-20146 Hamburg Germany phone: +49-(0)40-42838.7498 (office) +49-(0)40-42838.4591 (Billon) fax: +49-(0)40-42838.2344 email: dirk.enzmann(a)uni-hamburg.de www: http://www2.jura.uni-hamburg.de/instkrim/kriminologie/Mitarbeiter/Enzmann/E… *************************************************

1 0

size of EpiData note files
by epidata-list＠lists.umanitoba.ca 17 May '06

17 May '06

Unfortunately, if the size of the .not-files into which user-notes and EpiData generated notes are written exceeds about 64k, the coders can't enter further comments (although notes generated "automatically" via .chk-file commands will still be added). One solution to this problem is to close EpiData and to rename the .not-file. A new start of EpiData will then generate a new .not-file automatically. However, this solution is error prone, risky, and tedious: - you have to keep track of the size of the .not-files so that the coders can always enter their comments; - you may not overwrite renamed .not-files accidentally; - you have take care to collect/archive *all* renamed .not-files; - the solution is difficult to implement if the coders work independly and should not change files directly by themselves. Question: Is there any other solution? Is it possible to improve EpiData such that longer .not-files are possible? Current EpiData version: 3.1 (120306) Dirk ************************************************* Dr. Dirk Enzmann Institute of Criminal Sciences Dept. of Criminology Edmund-Siemers-Allee 1 D-20146 Hamburg Germany phone: +49-(0)40-42838.7498 (office) +49-(0)40-42838.4591 (Billon) fax: +49-(0)40-42838.2344 email: dirk.enzmann(a)uni-hamburg.de www: http://www2.jura.uni-hamburg.de/instkrim/kriminologie/Mitarbeiter/Enzmann/E… *************************************************

1 0

Cuantos registros soporta/Limits in the number of records
by epidata-list＠lists.umanitoba.ca 11 May '06

11 May '06

(In english only the main figures) Estimado Andrés, Teóricamente EpiData Entry no tiene límitaciones en cuanto al número de registros. Se han hecho pruebas con hasta 250.000 registros (tested with 250.000 records) en un solo archivo y el programa ha funcionado. Hay una limitación en cuanto a las variables que pueden ponerse en un solo archivo QES. Se pueden incluir todas las que se quiera, pero no se puede sobrepasar el límite de 999 líneas de texto en el archivo. (999 max number of lines in a QES file) Creemos que ninguna de ellas son limitaciones importantes. Es importante recordar que si se trabaja con el editor de EpiData el tamaño máximo de un archivo QES o CHK no puede sobrepasar los 64kb. (max. size in a QES or CHK file if you want to use it with the EpiData Editor). En cuanto a EpiData Analysis, se ha probado con 100.000 registros (tested with 100.000 records), sin problemas. Espero que este sea de ayuda, Saludos Pedro Pedro Arias Bohigas John Ericssons gatan, 12 5 tr 112 22 Stockholm Sweden Phone (cell)+46(0)734421130 > Today's Topics: > > 1. cuantos registros soporta (epidata-list(a)lists.umanitoba.ca) > > llevo años trabajando con Epidata y estoy realizando un proyecto pero > tengo dudas sobre la capacidad de manejo del programa, cuantos > registros me soporta tranquilamente epidata y cuantos el Epidata > Analisys. > > gracias.... > > andres hincapie.

1 0