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