Dear Jens,
Thank you very much. I followed your instructions and in the end was able to do a successful import. I discovered that indeed empty cells was the source of trouble. Once I had filled every empty cell with 9999, the import worked out beautifully. In my experiment, empty cells prevented paste even in fields other than boolean.
By the way, I only now discovered this manual: http://www.tbrieder.org/epidata/course_a.pdf It is really good, but I hadn't found it earlier for some reason, and I don't think it is linked on the epidata website.
Now I have come across the next hurdle: editing value labels. It seems I cannot alter value labels any more in Epidata manager. I guess the reason is to ensure not to accidentally change them, but I think it is quite common that at some point of data entry you realize you need to add another label, or just correct a typo in an existing label. How do you do that? I discovered that even when I exported the project to make a new project empty of data, the value labels remained uneditable. The same was also true when importing value labels through project/value labels/external from a previous project; I can't edit them.
Thank you again!
Pekka
2015-06-25 10:59 GMT+01:00 EpiData development and support < epidata-list@lists.umanitoba.ca>:
The short answer is: There is no safe way of changing from one variable (field) type to another . The reason for this is that in many cases we would have to make decisions which could alter data in a different way than the user intended.
The best good practice way of importing data from a spreadsheet was summarised by Jamie Hockin, but the aspect of deciding on field type was not mentioned. This is step 7 below.
The best practice is repeated below (hopefully in a structured and understandable way):
The step list is then:
- open and work in your spreadsheet file
- check each column, one by one and make sure that all cells in that
column have the same format. E.g. all cells in column M should be date if M contains dates 3. add one right most column, call it "dummy" and insert a 1 in all cells in that column in all rows which contains data. 4. Make sure all names of columns (in row 1) are valid. E.g. "age_of_this_patient" must be changed to "age" or "Thisverylongname" should be made shorter "thisname" 5. I change the decimal separator to . and I omit all thousand separators from formats. 6. I make sure that any "boolean"y/n" data are changed to 0 1 or 0 1 9, where 9 indicates blank. Boolean should be avoided since many software, e.g. those from M$ record no value as a "no" on export or conversion instead of as a "no value present". 7. I insert a row after the name row where I specifically change the content, such variables are converted correctly in Manager. E.g. in Denmark we have civil registration numbers which are 10 digits long, and we should read this as string to use it appropriately for a key. e.g. insert xxx in that place. 8. Then I mark the whole dataset as a block and copy to clipboard
After that import in Manager should be straight forward. As first part of the definition I would then in Manager:
a. look at data in browse. In particular I look at the first, the last and a few records in the middle to make sure that the import is working correctly. b. save the file in Manager c. open the file in EntryClient d. mark the added record (point 7 above) for deletion e. save the file f. pack the file in Manager, where I delete the record marked for deletion. g. Then I finalise the documentation of the data, e.g. add project descriptions and value labels or further controls such as range, calculations etc. h. I save the project i. I now run the "Data Content Validation" to find values not confirming to the content definition form point g. j. I run the "count by ID" documentation feature to make sure all id's are as expected. k. Any errors found in data or documentation are then fixed appropriately.
The same routine is applied whenever I am asked to look at data, which was entered or defined by other persons.
regards Jens Lauritsen EpiData Association
Den 25. jun. 2015, EpiData development and support < epidata-list@lists.umanitoba.ca> skrev:
I thought so too, thanks Jamie.
Can anyone from the development team comment on the issue of changing the field type and whether it is safe/wise to do so directly in XML? I tested it and it worked out fine, at least it appeared so, but there may be
issues
which are not immediately visible for a user.
Thanks!
Pekka
EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list