We have a DHIS2 tracker instance in which we initially imported OU metadata from another national level instance. There has been updates to the OU data in the source instance and we would like to reimport that OU data again into our system. To do so, we are trying to use Import/Export feature with the following configuration:
Import Mode: Commit
Identifier: AUTO
Import Strategy: Create and Update
However, the import process just skips everything:
You have no firm guarantee that exporting/importing between different versions are supported - formally it is not. In most cases export/import between close versions do work, but 2.26 to 2.30 is a large jump AND the whole design of the import “app” changed radically in 2.30.
Bottom line: yes, it would be problematic.
There are ways around this: The simplest would be to design a SQL View that dump out all the orgunits from the source system into the standard import/export CSV format - then you can import that into your 2.30 instance. Use the UID as the key field for that.
A more cumbersome approach would be to make a dump of the 2.26 db, restore it on another server (e.g. a local machine), upgrade it via 2.27, 2.28, 2.29 to 2.30 - and then export whatever you want.
I would use the first, simpler method if you only want to add/update orgunits. If you also want to add/update a range of other meta-data objects, then consider the upgrade method.
Column 14 is coordinates. I guess I can re import coordinates later somehow. So, I deleted the column from CSV and tried importing. Then, I got this error:
Yes, if you import coordinates via CSV, you must encapsulate the values in double-quotes etc - and in any case, I would only import POINT coordinates that way, not country borders and similar which might have thousands of vertices.
You cannot DELETE any of the CSV columns - you can only NULL them (the column order is fixed - you can usually drop of columns AT THE END of reach row but NOT columns “in between”, and I always prefer to include all columns including the blank ones).
Remember that whether you have a header row or not does not matter when it comes to CSV import files - the system expect columns in a specific order and that’s what you must feed it (as I said, you can disregard columns at the end but it’s safer to include all of them even if some are completely blank)
Please also note two aspects that often trips up CSV import:
Firstly, if your values are not encapsulated in e.g. double quotes, then ANY text value comprising any random comma will crash the import, because the system no longer see the column values expected.
Be on the lookout for any non-UTF-8 characters embedded in certain fields, especially if the data is coming from a 32-bits software system. (Should not be an issue if you export from one DHIS2 instance to another, but I’m just mentioning as a general educational point).
SELECT
base.name,
base.uid,
base.code,
parent.uid AS "parentuid",
base.shortname,
base.description,
base.openingdate,
base.closeddate,
base.comment,
base.featuretype
FROM public.organisationunit base
ON public.organisationunit parent ON base.parentid=parent.organisationunitid
