January 2005 - EpiData-list - University of Manitoba Mailing Lists

EpiData-list Digest, Vol 15, Issue 14
by epidata-list＠lists.umanitoba.ca 28 Jan '05

28 Jan '05

My e-mail system rejected the attached files because it is unsecure file. As I can see, the files in e-mail format. It will be better if files in TEXT or WORD foramt. Best regards and keep in touch Nabil Brandl

1 0

Re: EpiData-list Digest, Vol 15, Issue 14
by epidata-list＠lists.umanitoba.ca 28 Jan '05

28 Jan '05

My e-mail system rejected the attached files because it is unsecure file. As I can see, the files in e-mail format. It will be better if files in TEXT or WORD foramt. Best regards and keep in touch Nabil Brandl Denmark ----- Original Message ----- From: <epidata-list-request(a)lists.umanitoba.ca> To: <epidata-list(a)lists.umanitoba.ca> Sent: Friday, January 28, 2005 7:00 PM Subject: EpiData-list Digest, Vol 15, Issue 14 > Send EpiData-list mailing list submissions to > epidata-list(a)lists.umanitoba.ca > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.umanitoba.ca/mailman/listinfo/epidata-list > or, via email, send a message with subject or body 'help' to > epidata-list-request(a)lists.umanitoba.ca > > You can reach the person managing the list at > epidata-list-owner(a)lists.umanitoba.ca > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of EpiData-list digest..." > ---------------------------------------------------------------------------- ---- > Today's Topics: > > 1. just a trial after problems (epidata-list(a)lists.umanitoba.ca) > 2. ddd (epidata-list(a)lists.umanitoba.ca) > 3. essai? (epidata-list(a)lists.umanitoba.ca) > ---------------------------------------------------------------------------- ---- > _______________________________________________ > EpiData-list mailing list > EpiData-list(a)lists.umanitoba.ca > http://lists.umanitoba.ca/mailman/listinfo/epidata-list >

1 0

essai?
by epidata-list＠lists.umanitoba.ca 28 Jan '05

28 Jan '05

essai

1 0

ddd
by epidata-list＠lists.umanitoba.ca 28 Jan '05

28 Jan '05

ddddd

1 0

just a trial after problems
by epidata-list＠lists.umanitoba.ca 28 Jan '05

28 Jan '05

1 0

CALLING EPIDATA FUNCTIONS
by epidata-list＠lists.umanitoba.ca 26 Jan '05

26 Jan '05

Hi, I need to find out ways in which one could call epidata export function from epi2000. by this i have in mind the following example; ITEM Begin Execute c:\FILE NAME.REC End This sample will call the rec file and execute it. I need to do the same but this time, to export a file to maybe spss. How can i achieve this? Thanks Joel

1 0

Re: EpiData-list Digest, Vol 15, Issue 9 (Out of the office)
by epidata-list＠lists.umanitoba.ca 19 Jan '05

19 Jan '05

I will be out of the office from Thu. Jan. 13 through Fri. Jan. 14, 2005. I will reply to your email as soon as possible. If you need immediate assistance please call the DPCP Administrative Assistant, Bennie Daughtry at 545-4471.

1 0

Release of v3.1 EpiData
by epidata-list＠lists.umanitoba.ca 19 Jan '05

19 Jan '05

Version 3.1 of EpiData has been placed for download on: Http://www.epidata.dk/downloads/php In all translated versions. The major news is: a. Now double entry verification can be done by comparing with first entry at record and field level. b. Users can define their own functions and add to the Check file language. c. An extended BACKUP command with possibility for zip and encryption has been added. d. A new SHOWLASTRECORD command has been added in which the last record is shown on opening a rec file instead of "NEW record". -- Jens Lauritsen Coordinator and initiator of EpiData Project http://www.epidata.dk

1 0

RE: [EpiData-list] re: tables
by epidata-list＠lists.umanitoba.ca 18 Jan '05

18 Jan '05

Not a problem. Thanks for commenting. I believe he said it would Be sorted. Stay safe, Kelly -----Original Message----- From: epidata-list(a)lists.umanitoba.ca [mailto:epidata-list@lists.umanitoba.ca] Sent: Friday, January 14, 2005 5:16 PM To: epidata-list(a)lists.umanitoba.ca Subject: [EpiData-list] re: tables Oops - sorry Kelly. I had FREQ on the brain when I was reading the list the other day. Seems to me this is just a design feature that will come in place when the final work is done on TABLES. The cell & column orders should be handled the same was as for FREQ (i.e. numeric order for integer and float) as you and Jens point out. Jamie

1 0

EpiData and memory
by epidata-list＠lists.umanitoba.ca 17 Jan '05

17 Jan '05

>>> <epidata-list(a)lists.umanitoba.ca> 12-01-2005 19:51:45 >>> Hi, How much RAM is required to run EpiData 3.02? Very little RAM should be needed, but clearly it would depend on the complexity of your system. What I would do in such a situation is: a. Try on a different computer with same technical capability (ram, processor etc). b. Try with the samples accompanying EpiData (in samples folder). Run them all and if some do not work c. Try on more advanced computer d. After opening the rec file for data entry press F2 twice and see if the small "status window" comes up. If b and c works and a does not. Some aspect of that particular computer could be a problem. I have seen an instance in which calling external programs (e.g. execute epic ......) caused some "older" pc's to break down. With v3.1 the addition of the backup command remedies the need to call epic for more complicated backup including encryption of the backup copy. We will consider to extend the F2-F2 window with a memory status. regards Jens Lauritsen Initiator and Coordinator of EpiData Denmark

1 0

Table command behavior (sort order and alignment)
by epidata-list＠lists.umanitoba.ca 16 Jan '05

16 Jan '05

Controlling alignment and sorting are separate issues. This is the current strategy for implementation: 1. Sorting a. Numerical variables: by numerical code: 1,2,3..etc b. String variables: alfa: a,b,c,d,e,f .....1234 ABCEFG....123... But also that we should introduce options such as: /reverse : meaning reverse order /count: based on how many counts are in each category. if count and reverse are combined smallest counts first /limit: Only show categories with more records than the indicated value The options I do not expect to have ready in first version, but the general sort order will be fixed. WIth the suggestions of Jamie Hockin there is a good work-around of how users could have a string variable containing numerical codes could be sorted according to numerical value correctly. 2. Alignment Alignment is a completely different issue since this is not controlled by the individidual command, but rather by the formatting system of the output. All alignment and format is controlled by a "cascaded style sheet" contained in the file epiout.css. So for instance for the left most column this would be for right alignment: .firstcol {color: black ;font-size: 10pt;font-family: Fixedsys; font-weight: normal; text-align: right; padding-right: 10px; } and for left alignment: .firstcol {color: black ;font-size: 10pt;font-family: Fixedsys; font-weight: normal; text-align: left; padding-right: 10px; } I suggest test persons try to work out different variants of the style sheet and we could provide these with the installation routine. Currently we are working on build 18 of analysis. We have managed to incorporate the same source code for reading chk files as in epidata, such that we secure complete correspondance btw. the two programs. THe other major change has been to increase the precision of the internal representation of real numbers. Both changes require a lot of testing and going over functions, this is why there has been a while since release of last build. Kind regards Jens Lauritsen Initiator and Coordinator of EpiData.

1 0

re: tables
by epidata-list＠lists.umanitoba.ca 14 Jan '05

14 Jan '05

Oops - sorry Kelly. I had FREQ on the brain when I was reading the list the other day. Seems to me this is just a design feature that will come in place when the final work is done on TABLES. The cell & column orders should be handled the same was as for FREQ (i.e. numeric order for integer and float) as you and Jens point out. Jamie

1 0

RE: [EpiData-list] re: tables
by epidata-list＠lists.umanitoba.ca 14 Jan '05

14 Jan '05

Greetings, Jamie. I agree and I do understand "padding" strings. However, the Example I used was age as integer and sex and integer. The reason I chose this example was because using Epi604D Analysis and issuing the command Tables age sex the result was 1-n for age and 1-2 for sex. The data is stored as integers for both. Having to convert to string and then pad sounds a bit much. I suggest that the TABLES command using integers in both Fields be changed to produce the same ordering as FREQ. And, if padding is going to be so important, I agree there should be a function. I do appreciate your response and I have encountered a few other items Of Which I'm keeping track and will send along once I have exhausted my efforts. Have a great weekend and stay safe, Kelly Kelly Bussell CDC Atlanta -----Original Message----- From: epidata-list(a)lists.umanitoba.ca [mailto:epidata-list@lists.umanitoba.ca] Sent: Thursday, January 13, 2005 3:07 PM To: epidata-list(a)lists.umanitoba.ca Subject: [EpiData-list] re: tables Numeric fields display in the correct (ascending) order in FREQ. e.g. . freq time TIME No. % 0 1 2.50 1 1 2.50 14 1 2.50 22 1 2.50 31 1 2.50 ... 98 1 2.50 102 1 2.50 However, text fields are normally left-justified, even though FREQ shows them right-justified. With the same data and . define a ___ . let a = time . freq a A No. % 0 1 2.50 1 1 2.50 102 1 2.50 104 1 2.50 119 1 2.50 123 1 2.50 138 2 5.00 14 1 2.50 154 2 5.00 162 1 2.50 181 1 2.50 202 1 2.50 22 1 2.50 To right-justify the text field (or a copy of the text field would be safer as shown here): . define b ___ . b = copy(" ",1,3-length(trim(a)))+a . freq b B No. % 0 1 2.50 1 1 2.50 14 1 2.50 22 1 2.50 31 1 2.50 ... 92 1 2.50 97 1 2.50 98 1 2.50 102 1 2.50 104 1 2.50 I've used version 0.9 Build 17. This is a trick that is necessary with other systems as well, as strings tend to be stored left-justified unless you design it otherwise. Rather than have FREQ take care of this, it might be preferable to have a function to do the right-alignment of a field or do the left-padding of a string. e.g. b = LPAD(a) Jamie Hockin Public Health Agency of Canada

1 0

re: tables
by epidata-list＠lists.umanitoba.ca 13 Jan '05

13 Jan '05

Numeric fields display in the correct (ascending) order in FREQ. e.g. . freq time TIME No. % 0 1 2.50 1 1 2.50 14 1 2.50 22 1 2.50 31 1 2.50 ... 98 1 2.50 102 1 2.50 However, text fields are normally left-justified, even though FREQ shows them right-justified. With the same data and . define a ___ . let a = time . freq a A No. % 0 1 2.50 1 1 2.50 102 1 2.50 104 1 2.50 119 1 2.50 123 1 2.50 138 2 5.00 14 1 2.50 154 2 5.00 162 1 2.50 181 1 2.50 202 1 2.50 22 1 2.50 To right-justify the text field (or a copy of the text field would be safer as shown here): . define b ___ . b = copy(" ",1,3-length(trim(a)))+a . freq b B No. % 0 1 2.50 1 1 2.50 14 1 2.50 22 1 2.50 31 1 2.50 ... 92 1 2.50 97 1 2.50 98 1 2.50 102 1 2.50 104 1 2.50 I've used version 0.9 Build 17. This is a trick that is necessary with other systems as well, as strings tend to be stored left-justified unless you design it otherwise. Rather than have FREQ take care of this, it might be preferable to have a function to do the right-alignment of a field or do the left-padding of a string. e.g. b = LPAD(a) Jamie Hockin Public Health Agency of Canada

1 0

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

13 Jan '05

I will be out of the office from Thu. Jan. 13 through Fri. Jan. 14, 2005. I will reply to your email as soon as possible. If you need immediate assistance please call the DPCP Administrative Assistant, Bennie Daughtry at 545-4471.

1 0

EpiData and memory
by epidata-list＠lists.umanitoba.ca 12 Jan '05

12 Jan '05

Hi, How much RAM is required to run EpiData 3.02? One of my coworkers has had problems with her laptop computer freezing after coding 5-6 records. She has Windows 95 and 64MB of RAM. The CHK file that she is using is rather large -- it is 113 KB and 5322 lines long. The REC file is 85 KB. I have tried coding into the same REC file on a computer with 512MB of RAM. I had no problems after coding 15 records. Could my coworker be having a problem with RAM, or could there be a problem with the length of the CHK file? Any guidance would be greatly appreciated. Thanks, Katie

1 0

Tables in analysis and output direction
by epidata-list＠lists.umanitoba.ca 06 Jan '05

06 Jan '05

Regarding printing: The epi6 mode of routing to screen, printer etc. is not possible with windows, but we could consider a printing command, e.g.: print file.txt which would direct that file to printer. The user could then first make a log file (logopen) and then afterwards send that file to the printer I think we could also make a possibility to print the output window as such. Concering the sort order of tables: TABLES AGE SEX (age sex are numeric) resulted in AGE listed as > 1 >10 >11 >Etc. To >19 > 2 >20 Obviously this should be adapted such that there is by default a chronological sort of a numerical field and by values of a field with comment legal. User control of sort order is already on the wish list. I suggest members of the list add name and country when adding information to the list. But do not add e-mail since all mails are available when searching on internet, so SPAM systems could catch the mail adresses. Notice also that return fields of mails are not included in the mail list so the list does not show any e-mail adresses Regards Jens Lauritsen EpiData Association Denmark

1 0

tables
by epidata-list＠lists.umanitoba.ca 06 Jan '05

06 Jan '05

Greetings. Happy New Year! I am starting to use EpiData & Analysis and I think you are doing a nice job. I have not tried to access a printer directly in a .PGM as yet. I like very much the ability of Epi6 to allow me to program For users the destination of output e.g. screen, printer or to a file. I haven't seen any examples yet but in case there are none this Has always been important to site managers in the developing settings. I was doing FREQ and TABLES a moment ago and had the following result. FREQ AGE worked just fine TABLES AGE SEX (age sex are numeric) resulted in AGE listed as 1 10 11 Etc. To 19 2 20 21 22 Ect. To 29 3 30 31 I think this needs to be fixed. Or, what have I done wrong? Thank you and keep up the good work.

1 0

Encrypted fields in EpiData
by epidata-list＠lists.umanitoba.ca 04 Jan '05

04 Jan '05

The reason for placing the encrypted key encrypted in the header is: 1. There must be a place to compare the entered password with the true one Otherwise the decryption cannot work. You could argue that if a false key was provided, then nonsense would be returned and it would be up to the user to see that contents of an encrypted field was garbage. I would feel that was a dangerous situation, since if the user saved the record again, then the wrong key would be applied to garbage giving "double" garbage and no way to retrieve data. Another approach would be to save the key in a different file than the rec file header, but your arguments would apply equally to that. Certainly I can assure: The idea was NOT to provide a backdoor in case the user forgets their password. There is no way for EpiData crew or others to retrieve a forgotten passkey So the core of the reasoning has been: We rely on the "non-breakability" of the AES/Rijndael encryption principle and we need to know if the user uses the correct key - otherwise data could be lost. As a comparison, e.g. the password mechanism provided by WINZIP or Access is not reliable, there are programs on internet which will guess millions of passwords in few seconds for these - and find the one used. regards Jens Lauritsen Initiator and coordinator of EpiData

1 1

Line 640, error message
by epidata-list＠lists.umanitoba.ca 03 Jan '05

03 Jan '05

Thank you for the reply! Here is the answer in your text below: We should know more about the contents of the qes file to answer, e.g.: 1. How many lines in total --> So far it is 1616 lines. 2. How many fields are you planning --> the questionnaire is made of different categories. It is between 70-80 fields. 3. Are you using the "first word" or automatic options for creation of fields. --> First word. 4. which build and version of EpiData --> Version 3.02 5. Have you tried also with the v3.1 release candidate ? --> Unfortunately no. 6. Does preview of the same file work --> Yes! all the time with no problem at all! >>If you have as many fields as you indicate the error is either because you have more than 1000 lines in the qes file (which v3.1. will issue a warning for) or the automatic numbering of fields with similar names ran out of possible combinations. --> Does not EpiData take more than 1000 lines or? Happy 2005! /Ziad > I sent past message related to "field definition error in line > 640" message. > I tried to retype the QES form. So each five questions, I > switched the > QES file into REC file and did "checks" for it. I kept doing the > same > procedure, and I passed the line 640.

1 1