Good morning to all the list,
I'm experiencing a problem with my own epidata questionnaire setup, defined as follows:
MENU.qst - Q1.qst ----Q1_1qst - Q2.qst
MENU is just a initial menu that allows the user to select the questionnaire they want to enter or edit. Depending on entered number, the user is redirected using a IF…ELSE construct, like this:
IF selection = 1 THEN RELATE code q1 1 ENDIF IF selection = 2 THEN RELATE code q2 1 ENDIF
In MENU.qst, Q1.qst and Q2.qst there is a key, defined in each case as KEY UNIQUE 1, while Q1_1 is related to Q1 using the same key as Q1, but is defined as KEY 1.
When I try to merge together Q1 and Q2 everything goes fine, but when I try to export the data in Excel format the process exits with an error about the newly generated checkfile. In particular, the problem lies in the fact that the key in the new checkfile is defined simply as KEY 1, and not as KEY UNIQUE 1. However, to relate Q1 to Q2 needs the key to be defined as UNIQUE. I don't see any reason why while merging the new checkfile defines the key as not unique, since the codes are still unique also in the merged file.
There is any workaroud for this?
Thank you, Dario Vianello
Do you even need the checkfile to export to Excel? If Epidata is complaining about the checkfile for the merged file, you could just delete the checkfile before exporting. Q1.chk and Q2.chk will have your key field CODE defined as KEY UNIQUE 1, which is how your data entry is set up. Once you do the merge, do you even need CODE to be KEY?
Q1 can relate to Q2 (or vice versa), but why would you need to relate either of these to the merged file?
Perhaps I am not understanding the problem.
Jamie
On 2012-02-17, Dario wrote:
In MENU.qst, Q1.qst and Q2.qst there is a key, defined in each case as KEY UNIQUE 1, while Q1_1 is related to Q1 using the same key as Q1, but is defined as KEY 1.
When I try to merge together Q1 and Q2 everything goes fine, but when I try to export the data in Excel format the process exits with an error about the newly generated checkfile. In particular, the problem lies in the fact that the key in the new checkfile is defined simply as KEY 1, and not as KEY UNIQUE 1. However, to relate Q1 to Q2 needs the key to be defined as UNIQUE. I don't see any reason why while merging the new checkfile defines the key as not unique, since the codes are still unique also in the merged file.
The checkfile is checked but is not needed. However, since I'm trying to setup an automatic exporting using EpiC and I simply cannot relay on the users help in deleting a file inside the project folder, I was simply wondering if I was doing something wrong in the configuration.
Obviously again, I don't need any kind of relation in the merged file, but also in this case I cannot ask my users to delete the relate command from the checkfile.
Thanks in any case for your help ;-).
Dario
Il giorno 17/feb/2012, alle ore 16:52, epidata-list@lists.umanitoba.ca ha scritto:
Do you even need the checkfile to export to Excel? If Epidata is complaining about the checkfile for the merged file, you could just delete the checkfile before exporting. Q1.chk and Q2.chk will have your key field CODE defined as KEY UNIQUE 1, which is how your data entry is set up. Once you do the merge, do you even need CODE to be KEY?
Q1 can relate to Q2 (or vice versa), but why would you need to relate either of these to the merged file?
Perhaps I am not understanding the problem.
Jamie
On 2012-02-17, Dario wrote:
In MENU.qst, Q1.qst and Q2.qst there is a key, defined in each case as KEY UNIQUE 1, while Q1_1 is related to Q1 using the same key as Q1, but is defined as KEY 1.
When I try to merge together Q1 and Q2 everything goes fine, but when I try to export the data in Excel format the process exits with an error about the newly generated checkfile. In particular, the problem lies in the fact that the key in the new checkfile is defined simply as KEY 1, and not as KEY UNIQUE 1. However, to relate Q1 to Q2 needs the key to be defined as UNIQUE. I don't see any reason why while merging the new checkfile defines the key as not unique, since the codes are still unique also in the merged file.
EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list
If you are automating the merge and export with a batch file/windows shortcut, just include a line to delete the check file after the merge. Another option would be to do the merge and just forward the merged .rec file rather than having the export to Excel done locally. I realize they may want to use the Excel file, however.
Jamie
On 2012-02-17, at 2:14 PM, epidata-list@lists.umanitoba.ca wrote:
The checkfile is checked but is not needed. However, since I'm trying to setup an automatic exporting using EpiC and I simply cannot relay on the users help in deleting a file inside the project folder, I was simply wondering if I was doing something wrong in the configuration.
Obviously again, I don't need any kind of relation in the merged file, but also in this case I cannot ask my users to delete the relate command from the checkfile.
Thanks in any case for your help ;-).
Dario
Il giorno 17/feb/2012, alle ore 16:52, epidata-list@lists.umanitoba.ca ha scritto:
Do you even need the checkfile to export to Excel? If Epidata is complaining about the checkfile for the merged file, you could just delete the checkfile before exporting. Q1.chk and Q2.chk will have your key field CODE defined as KEY UNIQUE 1, which is how your data entry is set up. Once you do the merge, do you even need CODE to be KEY?
Q1 can relate to Q2 (or vice versa), but why would you need to relate either of these to the merged file?
Perhaps I am not understanding the problem.
Jamie
On 2012-02-17, Dario wrote:
In MENU.qst, Q1.qst and Q2.qst there is a key, defined in each case as KEY UNIQUE 1, while Q1_1 is related to Q1 using the same key as Q1, but is defined as KEY 1.
When I try to merge together Q1 and Q2 everything goes fine, but when I try to export the data in Excel format the process exits with an error about the newly generated checkfile. In particular, the problem lies in the fact that the key in the new checkfile is defined simply as KEY 1, and not as KEY UNIQUE 1. However, to relate Q1 to Q2 needs the key to be defined as UNIQUE. I don't see any reason why while merging the new checkfile defines the key as not unique, since the codes are still unique also in the merged file.
EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list
EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list
participants (1)
-
epidata-list＠lists.umanitoba.ca