Thanx for your quick response. I tried deleting it from the table. But If I see it has FK references to following table.
So before deleting that category-option-combo I need to delete references from all these tables.
Please let me know.
···
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
–