Deployable war for previous builds

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars

···

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

···

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Hi Mritunjay

As Lars says, if the categoryoptioncombos were not exported then that
would indeed have caused a problem. And/or if you were using internal
primary keys in your reports.

But is there a particular reason you need to rely on the import/export
functionality to do this? Did you try just taking a copy of the old
database and running the new war file against it? That tends to be
very reliable.

The best place to look for historic builds is
https://apps.dhis2.org/ci/. For each release number you will see that
there is a build history which maintains (a limited number of)
previous builds.

Cheers
Bob

···

On 14 July 2015 at 09:58, Lars Helge Øverland <larshelge@gmail.com> wrote:

Another explanation is that the category option combos for some reason were
not part of the exchange file, and was later re-generated in the destination
system. This will give different UIDs. Let me know..

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland <larshelge@gmail.com> > wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs
(stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the
build.

The database ids will likely change when you do an export followed by an
import.

When writing reports you should base it on the UIDs just for this reason.
I am guessing you relied on the database identifiers which then changed
during import-export.

regards,

Lars

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey >> <mritunjd@thoughtworks.com> wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance
running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few IDs, (e.g.-
category-option IDs) for few reports.
What I think because we have used the same metadata it should be same in
both.

BTW we have different Build Revision in both instances. So if there is a
way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you
Mritunjay Dubey

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

--
Lars Helge Øverland
Lead developer, DHIS 2
University of Oslo
Skype: larshelgeoverland
http://www.dhis2.org

--
Lars Helge Øverland
Lead developer, DHIS 2
University of Oslo
Skype: larshelgeoverland
http://www.dhis2.org

_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

Just adding to that

We had selected every metadata other than Validation-criteria & Report Table.

And while importing I could see

Importing 404 CategoryOptionCombos

So it should not be re-generated.

Thank You

···

On Tue, Jul 14, 2015 at 2:52 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Lars,

For us, the second explanation seems relevant. If I got to the source instance and pick a category option combo, in destination instance for same category option combo the UID is different.

For E.G.

If I pick the dataset Quarterly COIA Plus Dataset

In source instance, textbox in first row has id vIIFdYmaLk7-dCWAvZ8hcrs-val

In destination instance, textbox in first row has id vIIFdYmaLk7-s1oqQs4sQhc-val

Which I think because category option combo UID is changed.

Any clues what could be the reason for this?

Thank You

Mritunjay Dubey

On Tue, Jul 14, 2015 at 2:28 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars


Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Does this happen to be the “default” category option combo? If so, it will be different between different instances of the database, and you will thus need to sync this one manually between your instances.

Regards,

Jason

···

On Tue, Jul 14, 2015 at 11:43 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

---------- Forwarded message ----------
From: Mritunjay Dubey mritunjd@thoughtworks.com
Date: Tue, Jul 14, 2015 at 2:58 PM
Subject: Re: [Dhis2-devs] Deployable war for previous builds
To: Lars Helge Øverland larshelge@gmail.com

Just adding to that

We had selected every metadata other than Validation-criteria & Report Table.

And while importing I could see

Importing 404 CategoryOptionCombos

So it should not be re-generated.

Thank You


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 2:52 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Lars,

For us, the second explanation seems relevant. If I got to the source instance and pick a category option combo, in destination instance for same category option combo the UID is different.

For E.G.

If I pick the dataset Quarterly COIA Plus Dataset

In source instance, textbox in first row has id vIIFdYmaLk7-dCWAvZ8hcrs-val

In destination instance, textbox in first row has id vIIFdYmaLk7-s1oqQs4sQhc-val

Which I think because category option combo UID is changed.

Any clues what could be the reason for this?

Thank You

Mritunjay Dubey

On Tue, Jul 14, 2015 at 2:28 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars


Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Hey Jason,

Yes, I think it’s “default” category option combo, but I’m not sure about it. I can see in UI of dataset, it shows as “default” and the date-created for category option combo is the date when I set-up the instance.

So If it’s a “default” category-option-combo, what should I do to sync it between instances ?

Please let me know

Thank you

Mritunjay Dubey

···

On Tue, Jul 14, 2015 at 3:19 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Does this happen to be the “default” category option combo? If so, it will be different between different instances of the database, and you will thus need to sync this one manually between your instances.

Regards,

Jason

On Tue, Jul 14, 2015 at 11:43 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

---------- Forwarded message ----------
From: Mritunjay Dubey mritunjd@thoughtworks.com
Date: Tue, Jul 14, 2015 at 2:58 PM
Subject: Re: [Dhis2-devs] Deployable war for previous builds
To: Lars Helge Øverland larshelge@gmail.com

Just adding to that

We had selected every metadata other than Validation-criteria & Report Table.

And while importing I could see

Importing 404 CategoryOptionCombos

So it should not be re-generated.

Thank You


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 2:52 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Lars,

For us, the second explanation seems relevant. If I got to the source instance and pick a category option combo, in destination instance for same category option combo the UID is different.

For E.G.

If I pick the dataset Quarterly COIA Plus Dataset

In source instance, textbox in first row has id vIIFdYmaLk7-dCWAvZ8hcrs-val

In destination instance, textbox in first row has id vIIFdYmaLk7-s1oqQs4sQhc-val

Which I think because category option combo UID is changed.

Any clues what could be the reason for this?

Thank You

Mritunjay Dubey

On Tue, Jul 14, 2015 at 2:28 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars


Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

In this case, you should probably alter the “default” category option combo on the destination server to match that on the source server, if that is possible for you.

Something like

UPDATE categoryoptioncombo set uid = ‘XXXXXXXXX’ where categoryoptioncomboid = (SELECT categoryoptioncomboid from _categoryoptioncomboname where categoryoptioncomboname = ‘(default)’);

should work, where XXXXXXX is the uid of the source server.

Clear your server cache and rebuild all the resource tables, and you should be good to go.

Regards,

Jason

···

On Tue, Jul 14, 2015 at 12:09 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Jason,

Yes, I think it’s “default” category option combo, but I’m not sure about it. I can see in UI of dataset, it shows as “default” and the date-created for category option combo is the date when I set-up the instance.

So If it’s a “default” category-option-combo, what should I do to sync it between instances ?

Please let me know

Thank you

Mritunjay Dubey

On Tue, Jul 14, 2015 at 3:19 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Does this happen to be the “default” category option combo? If so, it will be different between different instances of the database, and you will thus need to sync this one manually between your instances.

Regards,

Jason

On Tue, Jul 14, 2015 at 11:43 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

---------- Forwarded message ----------
From: Mritunjay Dubey mritunjd@thoughtworks.com
Date: Tue, Jul 14, 2015 at 2:58 PM
Subject: Re: [Dhis2-devs] Deployable war for previous builds
To: Lars Helge Øverland larshelge@gmail.com

Just adding to that

We had selected every metadata other than Validation-criteria & Report Table.

And while importing I could see

Importing 404 CategoryOptionCombos

So it should not be re-generated.

Thank You


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 2:52 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Lars,

For us, the second explanation seems relevant. If I got to the source instance and pick a category option combo, in destination instance for same category option combo the UID is different.

For E.G.

If I pick the dataset Quarterly COIA Plus Dataset

In source instance, textbox in first row has id vIIFdYmaLk7-dCWAvZ8hcrs-val

In destination instance, textbox in first row has id vIIFdYmaLk7-s1oqQs4sQhc-val

Which I think because category option combo UID is changed.

Any clues what could be the reason for this?

Thank You

Mritunjay Dubey

On Tue, Jul 14, 2015 at 2:28 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars


Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Could you also please provide your DHIS 2 version and build rev? we should have fixed this issue 1-2 months ago (or at least a similar issue)

···

On Tue, Jul 14, 2015 at 5:14 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

In this case, you should probably alter the “default” category option combo on the destination server to match that on the source server, if that is possible for you.

Something like

UPDATE categoryoptioncombo set uid = ‘XXXXXXXXX’ where categoryoptioncomboid = (SELECT categoryoptioncomboid from _categoryoptioncomboname where categoryoptioncomboname = ‘(default)’);

should work, where XXXXXXX is the uid of the source server.

Clear your server cache and rebuild all the resource tables, and you should be good to go.

Regards,

Jason


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Morten

On Tue, Jul 14, 2015 at 12:09 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Jason,

Yes, I think it’s “default” category option combo, but I’m not sure about it. I can see in UI of dataset, it shows as “default” and the date-created for category option combo is the date when I set-up the instance.

So If it’s a “default” category-option-combo, what should I do to sync it between instances ?

Please let me know

Thank you

Mritunjay Dubey


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 3:19 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Does this happen to be the “default” category option combo? If so, it will be different between different instances of the database, and you will thus need to sync this one manually between your instances.

Regards,

Jason

On Tue, Jul 14, 2015 at 11:43 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

---------- Forwarded message ----------
From: Mritunjay Dubey mritunjd@thoughtworks.com
Date: Tue, Jul 14, 2015 at 2:58 PM
Subject: Re: [Dhis2-devs] Deployable war for previous builds
To: Lars Helge Øverland larshelge@gmail.com

Just adding to that

We had selected every metadata other than Validation-criteria & Report Table.

And while importing I could see

Importing 404 CategoryOptionCombos

So it should not be re-generated.

Thank You


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 2:52 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Lars,

For us, the second explanation seems relevant. If I got to the source instance and pick a category option combo, in destination instance for same category option combo the UID is different.

For E.G.

If I pick the dataset Quarterly COIA Plus Dataset

In source instance, textbox in first row has id vIIFdYmaLk7-dCWAvZ8hcrs-val

In destination instance, textbox in first row has id vIIFdYmaLk7-s1oqQs4sQhc-val

Which I think because category option combo UID is changed.

Any clues what could be the reason for this?

Thank You

Mritunjay Dubey

On Tue, Jul 14, 2015 at 2:28 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars


Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Hey Jason,

We are using DHIS 2.16 at both instances.

The build rev for source instance is 16594 and for destination instance it is 16598.

Let me know if it is fixed.

Thank you

···

On Tue, Jul 14, 2015 at 3:49 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Could you also please provide your DHIS 2 version and build rev? we should have fixed this issue 1-2 months ago (or at least a similar issue)


Morten

On Tue, Jul 14, 2015 at 5:14 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

In this case, you should probably alter the “default” category option combo on the destination server to match that on the source server, if that is possible for you.

Something like

UPDATE categoryoptioncombo set uid = ‘XXXXXXXXX’ where categoryoptioncomboid = (SELECT categoryoptioncomboid from _categoryoptioncomboname where categoryoptioncomboname = ‘(default)’);

should work, where XXXXXXX is the uid of the source server.

Clear your server cache and rebuild all the resource tables, and you should be good to go.

Regards,

Jason


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 12:09 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Jason,

Yes, I think it’s “default” category option combo, but I’m not sure about it. I can see in UI of dataset, it shows as “default” and the date-created for category option combo is the date when I set-up the instance.

So If it’s a “default” category-option-combo, what should I do to sync it between instances ?

Please let me know

Thank you

Mritunjay Dubey


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 3:19 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Does this happen to be the “default” category option combo? If so, it will be different between different instances of the database, and you will thus need to sync this one manually between your instances.

Regards,

Jason

On Tue, Jul 14, 2015 at 11:43 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

---------- Forwarded message ----------
From: Mritunjay Dubey mritunjd@thoughtworks.com
Date: Tue, Jul 14, 2015 at 2:58 PM
Subject: Re: [Dhis2-devs] Deployable war for previous builds
To: Lars Helge Øverland larshelge@gmail.com

Just adding to that

We had selected every metadata other than Validation-criteria & Report Table.

And while importing I could see

Importing 404 CategoryOptionCombos

So it should not be re-generated.

Thank You


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 2:52 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Lars,

For us, the second explanation seems relevant. If I got to the source instance and pick a category option combo, in destination instance for same category option combo the UID is different.

For E.G.

If I pick the dataset Quarterly COIA Plus Dataset

In source instance, textbox in first row has id vIIFdYmaLk7-dCWAvZ8hcrs-val

In destination instance, textbox in first row has id vIIFdYmaLk7-s1oqQs4sQhc-val

Which I think because category option combo UID is changed.

Any clues what could be the reason for this?

Thank You

Mritunjay Dubey

On Tue, Jul 14, 2015 at 2:28 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars


Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

That would explain it, as 2.16 is a year old now…

···

On Tue, Jul 14, 2015 at 12:32 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Jason,

We are using DHIS 2.16 at both instances.

The build rev for source instance is 16594 and for destination instance it is 16598.

Let me know if it is fixed.

Thank you


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 3:49 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Could you also please provide your DHIS 2 version and build rev? we should have fixed this issue 1-2 months ago (or at least a similar issue)


Morten

On Tue, Jul 14, 2015 at 5:14 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

In this case, you should probably alter the “default” category option combo on the destination server to match that on the source server, if that is possible for you.

Something like

UPDATE categoryoptioncombo set uid = ‘XXXXXXXXX’ where categoryoptioncomboid = (SELECT categoryoptioncomboid from _categoryoptioncomboname where categoryoptioncomboname = ‘(default)’);

should work, where XXXXXXX is the uid of the source server.

Clear your server cache and rebuild all the resource tables, and you should be good to go.

Regards,

Jason


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 12:09 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Jason,

Yes, I think it’s “default” category option combo, but I’m not sure about it. I can see in UI of dataset, it shows as “default” and the date-created for category option combo is the date when I set-up the instance.

So If it’s a “default” category-option-combo, what should I do to sync it between instances ?

Please let me know

Thank you

Mritunjay Dubey


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 3:19 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Does this happen to be the “default” category option combo? If so, it will be different between different instances of the database, and you will thus need to sync this one manually between your instances.

Regards,

Jason

On Tue, Jul 14, 2015 at 11:43 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

---------- Forwarded message ----------
From: Mritunjay Dubey mritunjd@thoughtworks.com
Date: Tue, Jul 14, 2015 at 2:58 PM
Subject: Re: [Dhis2-devs] Deployable war for previous builds
To: Lars Helge Øverland larshelge@gmail.com

Just adding to that

We had selected every metadata other than Validation-criteria & Report Table.

And while importing I could see

Importing 404 CategoryOptionCombos

So it should not be re-generated.

Thank You


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 2:52 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Lars,

For us, the second explanation seems relevant. If I got to the source instance and pick a category option combo, in destination instance for same category option combo the UID is different.

For E.G.

If I pick the dataset Quarterly COIA Plus Dataset

In source instance, textbox in first row has id vIIFdYmaLk7-dCWAvZ8hcrs-val

In destination instance, textbox in first row has id vIIFdYmaLk7-s1oqQs4sQhc-val

Which I think because category option combo UID is changed.

Any clues what could be the reason for this?

Thank You

Mritunjay Dubey

On Tue, Jul 14, 2015 at 2:28 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars


Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Dear Dubey,

Jason is right.

I have had trouble before with a similar issue doing imports.

One thing I keep in mind when importing to a new instance (without using a database dump) is to overwrite the “default” category option combo with the one I am carrying from the existing data.

To be safe, first import “categoryOptionCombos with depedencies” and then import the rest.

Alex

···

On Tue, Jul 14, 2015 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Could you also please provide your DHIS 2 version and build rev? we should have fixed this issue 1-2 months ago (or at least a similar issue)


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Morten

On Tue, Jul 14, 2015 at 5:14 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

In this case, you should probably alter the “default” category option combo on the destination server to match that on the source server, if that is possible for you.

Something like

UPDATE categoryoptioncombo set uid = ‘XXXXXXXXX’ where categoryoptioncomboid = (SELECT categoryoptioncomboid from _categoryoptioncomboname where categoryoptioncomboname = ‘(default)’);

should work, where XXXXXXX is the uid of the source server.

Clear your server cache and rebuild all the resource tables, and you should be good to go.

Regards,

Jason


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 12:09 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Jason,

Yes, I think it’s “default” category option combo, but I’m not sure about it. I can see in UI of dataset, it shows as “default” and the date-created for category option combo is the date when I set-up the instance.

So If it’s a “default” category-option-combo, what should I do to sync it between instances ?

Please let me know

Thank you

Mritunjay Dubey


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 3:19 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Does this happen to be the “default” category option combo? If so, it will be different between different instances of the database, and you will thus need to sync this one manually between your instances.

Regards,

Jason

On Tue, Jul 14, 2015 at 11:43 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

---------- Forwarded message ----------
From: Mritunjay Dubey mritunjd@thoughtworks.com
Date: Tue, Jul 14, 2015 at 2:58 PM
Subject: Re: [Dhis2-devs] Deployable war for previous builds
To: Lars Helge Øverland larshelge@gmail.com

Just adding to that

We had selected every metadata other than Validation-criteria & Report Table.

And while importing I could see

Importing 404 CategoryOptionCombos

So it should not be re-generated.

Thank You


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 2:52 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Lars,

For us, the second explanation seems relevant. If I got to the source instance and pick a category option combo, in destination instance for same category option combo the UID is different.

For E.G.

If I pick the dataset Quarterly COIA Plus Dataset

In source instance, textbox in first row has id vIIFdYmaLk7-dCWAvZ8hcrs-val

In destination instance, textbox in first row has id vIIFdYmaLk7-s1oqQs4sQhc-val

Which I think because category option combo UID is changed.

Any clues what could be the reason for this?

Thank You

Mritunjay Dubey

On Tue, Jul 14, 2015 at 2:28 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars


Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET

Kampala

Uganda

IT Consultant - BarefootPower Uganda Ltd, SmartSolar, Kenya

IT Specialist (Servers, Networks and Security, Health Information Systems - DHIS2 ) & Solar Consultant

+256 774149 775, + 256 759 800161

"I don’t want to be anything other than what I have been - one tree hill "

Yeah, I’m pretty sure this bug is still present in 2.16. Please try to fix it as Jason suggested…

···

On Tue, Jul 14, 2015 at 5:47 PM, Alex Tumwesigye atumwesigye@gmail.com wrote:

Dear Dubey,

Jason is right.

I have had trouble before with a similar issue doing imports.

One thing I keep in mind when importing to a new instance (without using a database dump) is to overwrite the “default” category option combo with the one I am carrying from the existing data.

To be safe, first import “categoryOptionCombos with depedencies” and then import the rest.

Alex


Morten

On Tue, Jul 14, 2015 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Could you also please provide your DHIS 2 version and build rev? we should have fixed this issue 1-2 months ago (or at least a similar issue)


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET

Kampala

Uganda

IT Consultant - BarefootPower Uganda Ltd, SmartSolar, Kenya

IT Specialist (Servers, Networks and Security, Health Information Systems - DHIS2 ) & Solar Consultant

+256 774149 775, + 256 759 800161

"I don’t want to be anything other than what I have been - one tree hill "


Morten

On Tue, Jul 14, 2015 at 5:14 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

In this case, you should probably alter the “default” category option combo on the destination server to match that on the source server, if that is possible for you.

Something like

UPDATE categoryoptioncombo set uid = ‘XXXXXXXXX’ where categoryoptioncomboid = (SELECT categoryoptioncomboid from _categoryoptioncomboname where categoryoptioncomboname = ‘(default)’);

should work, where XXXXXXX is the uid of the source server.

Clear your server cache and rebuild all the resource tables, and you should be good to go.

Regards,

Jason


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 12:09 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Jason,

Yes, I think it’s “default” category option combo, but I’m not sure about it. I can see in UI of dataset, it shows as “default” and the date-created for category option combo is the date when I set-up the instance.

So If it’s a “default” category-option-combo, what should I do to sync it between instances ?

Please let me know

Thank you

Mritunjay Dubey


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 3:19 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Does this happen to be the “default” category option combo? If so, it will be different between different instances of the database, and you will thus need to sync this one manually between your instances.

Regards,

Jason

On Tue, Jul 14, 2015 at 11:43 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

---------- Forwarded message ----------
From: Mritunjay Dubey mritunjd@thoughtworks.com
Date: Tue, Jul 14, 2015 at 2:58 PM
Subject: Re: [Dhis2-devs] Deployable war for previous builds
To: Lars Helge Øverland larshelge@gmail.com

Just adding to that

We had selected every metadata other than Validation-criteria & Report Table.

And while importing I could see

Importing 404 CategoryOptionCombos

So it should not be re-generated.

Thank You


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 2:52 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Lars,

For us, the second explanation seems relevant. If I got to the source instance and pick a category option combo, in destination instance for same category option combo the UID is different.

For E.G.

If I pick the dataset Quarterly COIA Plus Dataset

In source instance, textbox in first row has id vIIFdYmaLk7-dCWAvZ8hcrs-val

In destination instance, textbox in first row has id vIIFdYmaLk7-s1oqQs4sQhc-val

Which I think because category option combo UID is changed.

Any clues what could be the reason for this?

Thank You

Mritunjay Dubey

On Tue, Jul 14, 2015 at 2:28 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars


Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Yes please fix it.

Because it’s hard to know the “default” category-combo-option UID, If you don’t have database access to source instance.

Or If there is a way to get “default” category-combo-option UID please let me know.

Thank you

···

On Tue, Jul 14, 2015 at 4:30 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Yeah, I’m pretty sure this bug is still present in 2.16. Please try to fix it as Jason suggested…


Morten

On Tue, Jul 14, 2015 at 5:47 PM, Alex Tumwesigye atumwesigye@gmail.com wrote:

Dear Dubey,

Jason is right.

I have had trouble before with a similar issue doing imports.

One thing I keep in mind when importing to a new instance (without using a database dump) is to overwrite the “default” category option combo with the one I am carrying from the existing data.

To be safe, first import “categoryOptionCombos with depedencies” and then import the rest.

Alex

On Tue, Jul 14, 2015 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Could you also please provide your DHIS 2 version and build rev? we should have fixed this issue 1-2 months ago (or at least a similar issue)


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET

Kampala

Uganda

IT Consultant - BarefootPower Uganda Ltd, SmartSolar, Kenya

IT Specialist (Servers, Networks and Security, Health Information Systems - DHIS2 ) & Solar Consultant

+256 774149 775, + 256 759 800161

"I don’t want to be anything other than what I have been - one tree hill "


Morten

On Tue, Jul 14, 2015 at 5:14 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

In this case, you should probably alter the “default” category option combo on the destination server to match that on the source server, if that is possible for you.

Something like

UPDATE categoryoptioncombo set uid = ‘XXXXXXXXX’ where categoryoptioncomboid = (SELECT categoryoptioncomboid from _categoryoptioncomboname where categoryoptioncomboname = ‘(default)’);

should work, where XXXXXXX is the uid of the source server.

Clear your server cache and rebuild all the resource tables, and you should be good to go.

Regards,

Jason


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 12:09 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Jason,

Yes, I think it’s “default” category option combo, but I’m not sure about it. I can see in UI of dataset, it shows as “default” and the date-created for category option combo is the date when I set-up the instance.

So If it’s a “default” category-option-combo, what should I do to sync it between instances ?

Please let me know

Thank you

Mritunjay Dubey


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 3:19 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Does this happen to be the “default” category option combo? If so, it will be different between different instances of the database, and you will thus need to sync this one manually between your instances.

Regards,

Jason

On Tue, Jul 14, 2015 at 11:43 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

---------- Forwarded message ----------
From: Mritunjay Dubey mritunjd@thoughtworks.com
Date: Tue, Jul 14, 2015 at 2:58 PM
Subject: Re: [Dhis2-devs] Deployable war for previous builds
To: Lars Helge Øverland larshelge@gmail.com

Just adding to that

We had selected every metadata other than Validation-criteria & Report Table.

And while importing I could see

Importing 404 CategoryOptionCombos

So it should not be re-generated.

Thank You


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 2:52 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Lars,

For us, the second explanation seems relevant. If I got to the source instance and pick a category option combo, in destination instance for same category option combo the UID is different.

For E.G.

If I pick the dataset Quarterly COIA Plus Dataset

In source instance, textbox in first row has id vIIFdYmaLk7-dCWAvZ8hcrs-val

In destination instance, textbox in first row has id vIIFdYmaLk7-s1oqQs4sQhc-val

Which I think because category option combo UID is changed.

Any clues what could be the reason for this?

Thank You

Mritunjay Dubey

On Tue, Jul 14, 2015 at 2:28 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars


Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

It has been fixed. Just upgrade.

···

On Tue, Jul 14, 2015 at 4:30 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Yeah, I’m pretty sure this bug is still present in 2.16. Please try to fix it as Jason suggested…


Morten

On Tue, Jul 14, 2015 at 5:47 PM, Alex Tumwesigye atumwesigye@gmail.com wrote:

Dear Dubey,

Jason is right.

I have had trouble before with a similar issue doing imports.

One thing I keep in mind when importing to a new instance (without using a database dump) is to overwrite the “default” category option combo with the one I am carrying from the existing data.

To be safe, first import “categoryOptionCombos with depedencies” and then import the rest.

Alex

On Tue, Jul 14, 2015 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Could you also please provide your DHIS 2 version and build rev? we should have fixed this issue 1-2 months ago (or at least a similar issue)


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET

Kampala

Uganda

IT Consultant - BarefootPower Uganda Ltd, SmartSolar, Kenya

IT Specialist (Servers, Networks and Security, Health Information Systems - DHIS2 ) & Solar Consultant

+256 774149 775, + 256 759 800161

"I don’t want to be anything other than what I have been - one tree hill "


Morten

On Tue, Jul 14, 2015 at 5:14 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

In this case, you should probably alter the “default” category option combo on the destination server to match that on the source server, if that is possible for you.

Something like

UPDATE categoryoptioncombo set uid = ‘XXXXXXXXX’ where categoryoptioncomboid = (SELECT categoryoptioncomboid from _categoryoptioncomboname where categoryoptioncomboname = ‘(default)’);

should work, where XXXXXXX is the uid of the source server.

Clear your server cache and rebuild all the resource tables, and you should be good to go.

Regards,

Jason


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 12:09 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Jason,

Yes, I think it’s “default” category option combo, but I’m not sure about it. I can see in UI of dataset, it shows as “default” and the date-created for category option combo is the date when I set-up the instance.

So If it’s a “default” category-option-combo, what should I do to sync it between instances ?

Please let me know

Thank you

Mritunjay Dubey


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 3:19 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Does this happen to be the “default” category option combo? If so, it will be different between different instances of the database, and you will thus need to sync this one manually between your instances.

Regards,

Jason

On Tue, Jul 14, 2015 at 11:43 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

---------- Forwarded message ----------
From: Mritunjay Dubey mritunjd@thoughtworks.com
Date: Tue, Jul 14, 2015 at 2:58 PM
Subject: Re: [Dhis2-devs] Deployable war for previous builds
To: Lars Helge Øverland larshelge@gmail.com

Just adding to that

We had selected every metadata other than Validation-criteria & Report Table.

And while importing I could see

Importing 404 CategoryOptionCombos

So it should not be re-generated.

Thank You


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 2:52 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Lars,

For us, the second explanation seems relevant. If I got to the source instance and pick a category option combo, in destination instance for same category option combo the UID is different.

For E.G.

If I pick the dataset Quarterly COIA Plus Dataset

In source instance, textbox in first row has id vIIFdYmaLk7-dCWAvZ8hcrs-val

In destination instance, textbox in first row has id vIIFdYmaLk7-s1oqQs4sQhc-val

Which I think because category option combo UID is changed.

Any clues what could be the reason for this?

Thank You

Mritunjay Dubey

On Tue, Jul 14, 2015 at 2:28 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars


Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Hey Knut,

Upgrade means, Do I need to upgrade to 2.19, or somehow I can get a new revision of 2.16 only.

Please let me know.

Thank you

···

On Tue, Jul 14, 2015 at 6:08 PM, Knut Staring knutst@gmail.com wrote:

It has been fixed. Just upgrade.

On Jul 14, 2015 2:33 PM, “Mritunjay Dubey” mritunjd@thoughtworks.com wrote:

Yes please fix it.

Because it’s hard to know the “default” category-combo-option UID, If you don’t have database access to source instance.

Or If there is a way to get “default” category-combo-option UID please let me know.

Thank you


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 4:30 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Yeah, I’m pretty sure this bug is still present in 2.16. Please try to fix it as Jason suggested…


Morten

On Tue, Jul 14, 2015 at 5:47 PM, Alex Tumwesigye atumwesigye@gmail.com wrote:

Dear Dubey,

Jason is right.

I have had trouble before with a similar issue doing imports.

One thing I keep in mind when importing to a new instance (without using a database dump) is to overwrite the “default” category option combo with the one I am carrying from the existing data.

To be safe, first import “categoryOptionCombos with depedencies” and then import the rest.

Alex

On Tue, Jul 14, 2015 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Could you also please provide your DHIS 2 version and build rev? we should have fixed this issue 1-2 months ago (or at least a similar issue)


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET

Kampala

Uganda

IT Consultant - BarefootPower Uganda Ltd, SmartSolar, Kenya

IT Specialist (Servers, Networks and Security, Health Information Systems - DHIS2 ) & Solar Consultant

+256 774149 775, + 256 759 800161

"I don’t want to be anything other than what I have been - one tree hill "


Morten

On Tue, Jul 14, 2015 at 5:14 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

In this case, you should probably alter the “default” category option combo on the destination server to match that on the source server, if that is possible for you.

Something like

UPDATE categoryoptioncombo set uid = ‘XXXXXXXXX’ where categoryoptioncomboid = (SELECT categoryoptioncomboid from _categoryoptioncomboname where categoryoptioncomboname = ‘(default)’);

should work, where XXXXXXX is the uid of the source server.

Clear your server cache and rebuild all the resource tables, and you should be good to go.

Regards,

Jason


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 12:09 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Jason,

Yes, I think it’s “default” category option combo, but I’m not sure about it. I can see in UI of dataset, it shows as “default” and the date-created for category option combo is the date when I set-up the instance.

So If it’s a “default” category-option-combo, what should I do to sync it between instances ?

Please let me know

Thank you

Mritunjay Dubey


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 3:19 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Does this happen to be the “default” category option combo? If so, it will be different between different instances of the database, and you will thus need to sync this one manually between your instances.

Regards,

Jason

On Tue, Jul 14, 2015 at 11:43 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

---------- Forwarded message ----------
From: Mritunjay Dubey mritunjd@thoughtworks.com
Date: Tue, Jul 14, 2015 at 2:58 PM
Subject: Re: [Dhis2-devs] Deployable war for previous builds
To: Lars Helge Øverland larshelge@gmail.com

Just adding to that

We had selected every metadata other than Validation-criteria & Report Table.

And while importing I could see

Importing 404 CategoryOptionCombos

So it should not be re-generated.

Thank You


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 2:52 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Lars,

For us, the second explanation seems relevant. If I got to the source instance and pick a category option combo, in destination instance for same category option combo the UID is different.

For E.G.

If I pick the dataset Quarterly COIA Plus Dataset

In source instance, textbox in first row has id vIIFdYmaLk7-dCWAvZ8hcrs-val

In destination instance, textbox in first row has id vIIFdYmaLk7-s1oqQs4sQhc-val

Which I think because category option combo UID is changed.

Any clues what could be the reason for this?

Thank You

Mritunjay Dubey

On Tue, Jul 14, 2015 at 2:28 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars


Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

I meant 2.19

···

On Tue, Jul 14, 2015 at 6:08 PM, Knut Staring knutst@gmail.com wrote:

It has been fixed. Just upgrade.

On Jul 14, 2015 2:33 PM, “Mritunjay Dubey” mritunjd@thoughtworks.com wrote:

Yes please fix it.

Because it’s hard to know the “default” category-combo-option UID, If you don’t have database access to source instance.

Or If there is a way to get “default” category-combo-option UID please let me know.

Thank you


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 4:30 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Yeah, I’m pretty sure this bug is still present in 2.16. Please try to fix it as Jason suggested…


Morten

On Tue, Jul 14, 2015 at 5:47 PM, Alex Tumwesigye atumwesigye@gmail.com wrote:

Dear Dubey,

Jason is right.

I have had trouble before with a similar issue doing imports.

One thing I keep in mind when importing to a new instance (without using a database dump) is to overwrite the “default” category option combo with the one I am carrying from the existing data.

To be safe, first import “categoryOptionCombos with depedencies” and then import the rest.

Alex

On Tue, Jul 14, 2015 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Could you also please provide your DHIS 2 version and build rev? we should have fixed this issue 1-2 months ago (or at least a similar issue)


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET

Kampala

Uganda

IT Consultant - BarefootPower Uganda Ltd, SmartSolar, Kenya

IT Specialist (Servers, Networks and Security, Health Information Systems - DHIS2 ) & Solar Consultant

+256 774149 775, + 256 759 800161

"I don’t want to be anything other than what I have been - one tree hill "


Morten

On Tue, Jul 14, 2015 at 5:14 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

In this case, you should probably alter the “default” category option combo on the destination server to match that on the source server, if that is possible for you.

Something like

UPDATE categoryoptioncombo set uid = ‘XXXXXXXXX’ where categoryoptioncomboid = (SELECT categoryoptioncomboid from _categoryoptioncomboname where categoryoptioncomboname = ‘(default)’);

should work, where XXXXXXX is the uid of the source server.

Clear your server cache and rebuild all the resource tables, and you should be good to go.

Regards,

Jason


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 12:09 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Jason,

Yes, I think it’s “default” category option combo, but I’m not sure about it. I can see in UI of dataset, it shows as “default” and the date-created for category option combo is the date when I set-up the instance.

So If it’s a “default” category-option-combo, what should I do to sync it between instances ?

Please let me know

Thank you

Mritunjay Dubey


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 3:19 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Does this happen to be the “default” category option combo? If so, it will be different between different instances of the database, and you will thus need to sync this one manually between your instances.

Regards,

Jason

On Tue, Jul 14, 2015 at 11:43 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

---------- Forwarded message ----------
From: Mritunjay Dubey mritunjd@thoughtworks.com
Date: Tue, Jul 14, 2015 at 2:58 PM
Subject: Re: [Dhis2-devs] Deployable war for previous builds
To: Lars Helge Øverland larshelge@gmail.com

Just adding to that

We had selected every metadata other than Validation-criteria & Report Table.

And while importing I could see

Importing 404 CategoryOptionCombos

So it should not be re-generated.

Thank You


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 2:52 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Lars,

For us, the second explanation seems relevant. If I got to the source instance and pick a category option combo, in destination instance for same category option combo the UID is different.

For E.G.

If I pick the dataset Quarterly COIA Plus Dataset

In source instance, textbox in first row has id vIIFdYmaLk7-dCWAvZ8hcrs-val

In destination instance, textbox in first row has id vIIFdYmaLk7-s1oqQs4sQhc-val

Which I think because category option combo UID is changed.

Any clues what could be the reason for this?

Thank You

Mritunjay Dubey

On Tue, Jul 14, 2015 at 2:28 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars


Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Hello all,

So as suggested I tried to update the “default” category-option-combo UID to the UID of source instance. But it didn’t work.

The reason was I already have a category-option-combo with same UID which also has name “default”. I think which came after import. So now it has two “default” category-option-combos, and on UI it’s showing the one which got generated automatically, not the one which I imported.

I’ll just show the workaround

**Selected****details of **categoryoptioncombos which have name **“default” **

select * from categoryoptioncombo where categoryoptioncomboid in

(select categoryoptioncomboid from categorycombos_optioncombos where categorycomboid =

(select categorycomboid from categorycombo where name=‘default’));

It gave me 2 results

categoryoptioncomboid | uid | code | created | lastupdated

···

On Tue, Jul 14, 2015 at 7:01 PM, Knut Staring knutst@gmail.com wrote:

I meant 2.19

On Jul 14, 2015 2:47 PM, “Mritunjay Dubey” mritunjd@thoughtworks.com wrote:

Hey Knut,

Upgrade means, Do I need to upgrade to 2.19, or somehow I can get a new revision of 2.16 only.

Please let me know.

Thank you

On Tue, Jul 14, 2015 at 6:08 PM, Knut Staring knutst@gmail.com wrote:

It has been fixed. Just upgrade.

On Jul 14, 2015 2:33 PM, “Mritunjay Dubey” mritunjd@thoughtworks.com wrote:

Yes please fix it.

Because it’s hard to know the “default” category-combo-option UID, If you don’t have database access to source instance.

Or If there is a way to get “default” category-combo-option UID please let me know.

Thank you


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 4:30 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Yeah, I’m pretty sure this bug is still present in 2.16. Please try to fix it as Jason suggested…


Morten

On Tue, Jul 14, 2015 at 5:47 PM, Alex Tumwesigye atumwesigye@gmail.com wrote:

Dear Dubey,

Jason is right.

I have had trouble before with a similar issue doing imports.

One thing I keep in mind when importing to a new instance (without using a database dump) is to overwrite the “default” category option combo with the one I am carrying from the existing data.

To be safe, first import “categoryOptionCombos with depedencies” and then import the rest.

Alex

On Tue, Jul 14, 2015 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Could you also please provide your DHIS 2 version and build rev? we should have fixed this issue 1-2 months ago (or at least a similar issue)


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET

Kampala

Uganda

IT Consultant - BarefootPower Uganda Ltd, SmartSolar, Kenya

IT Specialist (Servers, Networks and Security, Health Information Systems - DHIS2 ) & Solar Consultant

+256 774149 775, + 256 759 800161

"I don’t want to be anything other than what I have been - one tree hill "


Morten

On Tue, Jul 14, 2015 at 5:14 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

In this case, you should probably alter the “default” category option combo on the destination server to match that on the source server, if that is possible for you.

Something like

UPDATE categoryoptioncombo set uid = ‘XXXXXXXXX’ where categoryoptioncomboid = (SELECT categoryoptioncomboid from _categoryoptioncomboname where categoryoptioncomboname = ‘(default)’);

should work, where XXXXXXX is the uid of the source server.

Clear your server cache and rebuild all the resource tables, and you should be good to go.

Regards,

Jason


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 12:09 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Jason,

Yes, I think it’s “default” category option combo, but I’m not sure about it. I can see in UI of dataset, it shows as “default” and the date-created for category option combo is the date when I set-up the instance.

So If it’s a “default” category-option-combo, what should I do to sync it between instances ?

Please let me know

Thank you

Mritunjay Dubey


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 3:19 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Does this happen to be the “default” category option combo? If so, it will be different between different instances of the database, and you will thus need to sync this one manually between your instances.

Regards,

Jason

On Tue, Jul 14, 2015 at 11:43 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

---------- Forwarded message ----------
From: Mritunjay Dubey mritunjd@thoughtworks.com
Date: Tue, Jul 14, 2015 at 2:58 PM
Subject: Re: [Dhis2-devs] Deployable war for previous builds
To: Lars Helge Øverland larshelge@gmail.com

Just adding to that

We had selected every metadata other than Validation-criteria & Report Table.

And while importing I could see

Importing 404 CategoryOptionCombos

So it should not be re-generated.

Thank You


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 2:52 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Lars,

For us, the second explanation seems relevant. If I got to the source instance and pick a category option combo, in destination instance for same category option combo the UID is different.

For E.G.

If I pick the dataset Quarterly COIA Plus Dataset

In source instance, textbox in first row has id vIIFdYmaLk7-dCWAvZ8hcrs-val

In destination instance, textbox in first row has id vIIFdYmaLk7-s1oqQs4sQhc-val

Which I think because category option combo UID is changed.

Any clues what could be the reason for this?

Thank You

Mritunjay Dubey

On Tue, Jul 14, 2015 at 2:28 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars


Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Hi

You probably want to delete the “default” that was created during import, I assume no FK is attached to it. After you have done this, you should be able to change the UID of the other “default” COC to “dCWAvZ8hcrs”.

This is the way we have solved it a few places (before it was fixed in the code).

···

On Wed, Jul 15, 2015 at 1:28 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hello all,

So as suggested I tried to update the “default” category-option-combo UID to the UID of source instance. But it didn’t work.

The reason was I already have a category-option-combo with same UID which also has name “default”. I think which came after import. So now it has two “default” category-option-combos, and on UI it’s showing the one which got generated automatically, not the one which I imported.

I’ll just show the workaround

**Selected****details of **categoryoptioncombos which have name **“default” **

select * from categoryoptioncombo where categoryoptioncomboid in

(select categoryoptioncomboid from categorycombos_optioncombos where categorycomboid =

(select categorycomboid from categorycombo where name=‘default’));

It gave me 2 results

categoryoptioncomboid | uid | code | created | lastupdated

-----------------------±------------±-----±------------------------±------------------------

16 | SVxKSIBjYFR | | 2015-07-15 05:38:33.869 | 2015-07-15 05:38:33.869

29614 | dCWAvZ8hcrs | | 2012-02-11 11:27:56 | 2015-07-15 05:43:16.587

**First one which is created in destination instance automatically, and second one which is imported. **

Now I tried changing the UID

                      update categoryoptioncombo set uid = 'dCWAvZ8hcrs' where categoryoptioncomboid = 16;

It failed with an error saying bellow

ERROR: duplicate key value violates unique constraint “categoryoptioncombo_uid_key”

DETAIL: Key (uid)=(dCWAvZ8hcrs) already exists.

Please suggest, what should be workaround.

Thank you

Mritunjay


Morten

On Tue, Jul 14, 2015 at 7:01 PM, Knut Staring knutst@gmail.com wrote:

I meant 2.19

On Jul 14, 2015 2:47 PM, “Mritunjay Dubey” mritunjd@thoughtworks.com wrote:

Hey Knut,

Upgrade means, Do I need to upgrade to 2.19, or somehow I can get a new revision of 2.16 only.

Please let me know.

Thank you

On Tue, Jul 14, 2015 at 6:08 PM, Knut Staring knutst@gmail.com wrote:

It has been fixed. Just upgrade.

On Jul 14, 2015 2:33 PM, “Mritunjay Dubey” mritunjd@thoughtworks.com wrote:

Yes please fix it.

Because it’s hard to know the “default” category-combo-option UID, If you don’t have database access to source instance.

Or If there is a way to get “default” category-combo-option UID please let me know.

Thank you


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 4:30 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Yeah, I’m pretty sure this bug is still present in 2.16. Please try to fix it as Jason suggested…


Morten

On Tue, Jul 14, 2015 at 5:47 PM, Alex Tumwesigye atumwesigye@gmail.com wrote:

Dear Dubey,

Jason is right.

I have had trouble before with a similar issue doing imports.

One thing I keep in mind when importing to a new instance (without using a database dump) is to overwrite the “default” category option combo with the one I am carrying from the existing data.

To be safe, first import “categoryOptionCombos with depedencies” and then import the rest.

Alex

On Tue, Jul 14, 2015 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Could you also please provide your DHIS 2 version and build rev? we should have fixed this issue 1-2 months ago (or at least a similar issue)


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET

Kampala

Uganda

IT Consultant - BarefootPower Uganda Ltd, SmartSolar, Kenya

IT Specialist (Servers, Networks and Security, Health Information Systems - DHIS2 ) & Solar Consultant

+256 774149 775, + 256 759 800161

"I don’t want to be anything other than what I have been - one tree hill "


Morten

On Tue, Jul 14, 2015 at 5:14 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

In this case, you should probably alter the “default” category option combo on the destination server to match that on the source server, if that is possible for you.

Something like

UPDATE categoryoptioncombo set uid = ‘XXXXXXXXX’ where categoryoptioncomboid = (SELECT categoryoptioncomboid from _categoryoptioncomboname where categoryoptioncomboname = ‘(default)’);

should work, where XXXXXXX is the uid of the source server.

Clear your server cache and rebuild all the resource tables, and you should be good to go.

Regards,

Jason


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 12:09 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Jason,

Yes, I think it’s “default” category option combo, but I’m not sure about it. I can see in UI of dataset, it shows as “default” and the date-created for category option combo is the date when I set-up the instance.

So If it’s a “default” category-option-combo, what should I do to sync it between instances ?

Please let me know

Thank you

Mritunjay Dubey


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 3:19 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Does this happen to be the “default” category option combo? If so, it will be different between different instances of the database, and you will thus need to sync this one manually between your instances.

Regards,

Jason

On Tue, Jul 14, 2015 at 11:43 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

---------- Forwarded message ----------
From: Mritunjay Dubey mritunjd@thoughtworks.com
Date: Tue, Jul 14, 2015 at 2:58 PM
Subject: Re: [Dhis2-devs] Deployable war for previous builds
To: Lars Helge Øverland larshelge@gmail.com

Just adding to that

We had selected every metadata other than Validation-criteria & Report Table.

And while importing I could see

Importing 404 CategoryOptionCombos

So it should not be re-generated.

Thank You


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 2:52 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Lars,

For us, the second explanation seems relevant. If I got to the source instance and pick a category option combo, in destination instance for same category option combo the UID is different.

For E.G.

If I pick the dataset Quarterly COIA Plus Dataset

In source instance, textbox in first row has id vIIFdYmaLk7-dCWAvZ8hcrs-val

In destination instance, textbox in first row has id vIIFdYmaLk7-s1oqQs4sQhc-val

Which I think because category option combo UID is changed.

Any clues what could be the reason for this?

Thank You

Mritunjay Dubey

On Tue, Jul 14, 2015 at 2:28 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars


Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

Hey Mortan,

Thanx for your quick response. I tried deleting it from the table. But If I see it has FK references to following table.

categorycombos_optioncombos

categoryoptioncombos_categoryoptions

expressionoptioncombo

So before deleting that category-option-combo I need to delete references from all these tables.

Is this the way I should do it ?

Please let me know.

Thank you

Mritunjay

···

On Wed, Jul 15, 2015 at 12:02 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi

You probably want to delete the “default” that was created during import, I assume no FK is attached to it. After you have done this, you should be able to change the UID of the other “default” COC to “dCWAvZ8hcrs”.

This is the way we have solved it a few places (before it was fixed in the code).


Morten

On Wed, Jul 15, 2015 at 1:28 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hello all,

So as suggested I tried to update the “default” category-option-combo UID to the UID of source instance. But it didn’t work.

The reason was I already have a category-option-combo with same UID which also has name “default”. I think which came after import. So now it has two “default” category-option-combos, and on UI it’s showing the one which got generated automatically, not the one which I imported.

I’ll just show the workaround

**Selected****details of **categoryoptioncombos which have name **“default” **

select * from categoryoptioncombo where categoryoptioncomboid in

(select categoryoptioncomboid from categorycombos_optioncombos where categorycomboid =

(select categorycomboid from categorycombo where name=‘default’));

It gave me 2 results

categoryoptioncomboid | uid | code | created | lastupdated

-----------------------±------------±-----±------------------------±------------------------

16 | SVxKSIBjYFR | | 2015-07-15 05:38:33.869 | 2015-07-15 05:38:33.869

29614 | dCWAvZ8hcrs | | 2012-02-11 11:27:56 | 2015-07-15 05:43:16.587

**First one which is created in destination instance automatically, and second one which is imported. **

Now I tried changing the UID

                      update categoryoptioncombo set uid = 'dCWAvZ8hcrs' where categoryoptioncomboid = 16;

It failed with an error saying bellow

ERROR: duplicate key value violates unique constraint “categoryoptioncombo_uid_key”

DETAIL: Key (uid)=(dCWAvZ8hcrs) already exists.

Please suggest, what should be workaround.

Thank you

Mritunjay

On Tue, Jul 14, 2015 at 7:01 PM, Knut Staring knutst@gmail.com wrote:

I meant 2.19

On Jul 14, 2015 2:47 PM, “Mritunjay Dubey” mritunjd@thoughtworks.com wrote:

Hey Knut,

Upgrade means, Do I need to upgrade to 2.19, or somehow I can get a new revision of 2.16 only.

Please let me know.

Thank you

On Tue, Jul 14, 2015 at 6:08 PM, Knut Staring knutst@gmail.com wrote:

It has been fixed. Just upgrade.

On Jul 14, 2015 2:33 PM, “Mritunjay Dubey” mritunjd@thoughtworks.com wrote:

Yes please fix it.

Because it’s hard to know the “default” category-combo-option UID, If you don’t have database access to source instance.

Or If there is a way to get “default” category-combo-option UID please let me know.

Thank you


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 4:30 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Yeah, I’m pretty sure this bug is still present in 2.16. Please try to fix it as Jason suggested…


Morten

On Tue, Jul 14, 2015 at 5:47 PM, Alex Tumwesigye atumwesigye@gmail.com wrote:

Dear Dubey,

Jason is right.

I have had trouble before with a similar issue doing imports.

One thing I keep in mind when importing to a new instance (without using a database dump) is to overwrite the “default” category option combo with the one I am carrying from the existing data.

To be safe, first import “categoryOptionCombos with depedencies” and then import the rest.

Alex

On Tue, Jul 14, 2015 at 1:19 PM, Morten Olav Hansen mortenoh@gmail.com wrote:

Could you also please provide your DHIS 2 version and build rev? we should have fixed this issue 1-2 months ago (or at least a similar issue)


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Alex Tumwesigye

Technical Advisor - DHIS2 (Consultant),
Ministry of Health/AFENET

Kampala

Uganda

IT Consultant - BarefootPower Uganda Ltd, SmartSolar, Kenya

IT Specialist (Servers, Networks and Security, Health Information Systems - DHIS2 ) & Solar Consultant

+256 774149 775, + 256 759 800161

"I don’t want to be anything other than what I have been - one tree hill "


Morten

On Tue, Jul 14, 2015 at 5:14 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

In this case, you should probably alter the “default” category option combo on the destination server to match that on the source server, if that is possible for you.

Something like

UPDATE categoryoptioncombo set uid = ‘XXXXXXXXX’ where categoryoptioncomboid = (SELECT categoryoptioncomboid from _categoryoptioncomboname where categoryoptioncomboname = ‘(default)’);

should work, where XXXXXXX is the uid of the source server.

Clear your server cache and rebuild all the resource tables, and you should be good to go.

Regards,

Jason


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On Tue, Jul 14, 2015 at 12:09 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Jason,

Yes, I think it’s “default” category option combo, but I’m not sure about it. I can see in UI of dataset, it shows as “default” and the date-created for category option combo is the date when I set-up the instance.

So If it’s a “default” category-option-combo, what should I do to sync it between instances ?

Please let me know

Thank you

Mritunjay Dubey


Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 3:19 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Does this happen to be the “default” category option combo? If so, it will be different between different instances of the database, and you will thus need to sync this one manually between your instances.

Regards,

Jason

On Tue, Jul 14, 2015 at 11:43 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

---------- Forwarded message ----------
From: Mritunjay Dubey mritunjd@thoughtworks.com
Date: Tue, Jul 14, 2015 at 2:58 PM
Subject: Re: [Dhis2-devs] Deployable war for previous builds
To: Lars Helge Øverland larshelge@gmail.com

Just adding to that

We had selected every metadata other than Validation-criteria & Report Table.

And while importing I could see

Importing 404 CategoryOptionCombos

So it should not be re-generated.

Thank You


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On Tue, Jul 14, 2015 at 2:52 PM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey Lars,

For us, the second explanation seems relevant. If I got to the source instance and pick a category option combo, in destination instance for same category option combo the UID is different.

For E.G.

If I pick the dataset Quarterly COIA Plus Dataset

In source instance, textbox in first row has id vIIFdYmaLk7-dCWAvZ8hcrs-val

In destination instance, textbox in first row has id vIIFdYmaLk7-s1oqQs4sQhc-val

Which I think because category option combo UID is changed.

Any clues what could be the reason for this?

Thank You

Mritunjay Dubey

On Tue, Jul 14, 2015 at 2:28 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Another explanation is that the category option combos for some reason were not part of the exchange file, and was later re-generated in the destination system. This will give different UIDs. Let me know…

On Tue, Jul 14, 2015 at 10:47 AM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Mritunjay,

are you referring the the internal database identifiers, or the UIDs (stable identifiers) ?

The UIDs will (should) not change and this has nothing to do with the build.

The database ids will likely change when you do an export followed by an import.

When writing reports you should base it on the UIDs just for this reason. I am guessing you relied on the database identifiers which then changed during import-export.

regards,

Lars


Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org

On Tue, Jul 14, 2015 at 8:16 AM, Mritunjay Dubey mritunjd@thoughtworks.com wrote:

Hey team,

We are setting up a new instance of DHIS. We had got already an instance running. So we exported metadata from there and imported in new one.

But If we see, we are getting a difference between few **IDs, (**e.g.- category-option IDs) for few reports.

What I think because we have used the same metadata it should be same in both.

BTW we have different **Build Revision **in both instances. So if there is a way to get the artifacts of previous builds, it might solve the problem.

Kindly let me know.

Thank you

Mritunjay Dubey


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

http://www.dhis2.org