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 line640" 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.
The use of the strong AES (Rijndael) cipher to encrypt fields in EpiData is laudable, but what is the logic of embedding the password encrypted with itself in the REC file header? Surely this makes a dictionary attack against the password much, much easier than it would be otherwise? What is gained by having the encrypted password in the header? Surely either the user knows the password, or they don't. Why leaves clues in the header which can help someone else find the password? If the idea is to provide a backdoor in case the user forgets their password, then why use a strong algorithm like AES in the first place?
None of this worries me - I am just curious as to why the design decision was made.
Tim C
participants (1)
-
epidata-list＠lists.umanitoba.ca