[EpiData-list] Importing data to Epidata (v.188.8.131.52)
EpiData development and support
epidata-list at lists.umanitoba.ca
Sun Jun 28 15:36:00 CDT 2015
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!
2015-06-25 10:59 GMT+01:00 EpiData development and support <
epidata-list at 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:
> 1. open and work in your spreadsheet file
> 2. 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
> 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 at 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
> > which are not immediately visible for a user.
> > Thanks!
> > Pekka
> EpiData-list mailing list
> EpiData-list at lists.umanitoba.ca
More information about the EpiData-list