changing data sources in same project

[ry1633]

Hi all,

I'm wondering how to add and change a data source in same project, and then link an existing package to the other data source.  My issue is that my two data sources in Dev/Test and Production are named different, with different oracle tns connections.     So I need to get the Prod data source connection into my project and map the package to it.

What I did is kept the original data source label the same and changed the Content Manager Data Source and Schema to the Prod ones.   I tested the connection and it seemed to be OK.   Is this the right way or is there a better way?   I came across this link.   

https://www.ibm.com/developerworks/community/forums/html/topic?id=8777e383-ef6f-4cce-ac23-605930b893de

[bdbits]

The data source names as set up in Cognos should be the same across instances. When you transfer the package, Cognos will look for the data source by name. The connection itself, how it is defined in admin, will not matter - it is the name that is important.

[ry1633]

In my case the Dev and Test environments have Oracle TNS connections (and names) than the Prod one.   So I had to install a completely different instance of FM and configured its Cognos Configuration (other wise I couldn't see the Prod data source at all).     Then what I did is:

-kept the label name of the data source the same for the package
-changed the Content Manager Data source to the Prod source
-changed the Schema to the Prod schema

[ry1633]

I found this link in the IBM Knowledge Center

http://www.ibm.com/support/knowledgecenter/SSRL5J_1.0.1/com.ibm.swg.ba.cognos.ug_fm.10.1.1.doc/t_remap_an_object_to_a_new_source.html

But I am using Cognos FM 10.2.1 and when I right-click any of my own objects in the Project Viewer pane, I do not see any of those options listed.

[MFGF]

I found this link in the IBM Knowledge Center

http://www.ibm.com/support/knowledgecenter/SSRL5J_1.0.1/com.ibm.swg.ba.cognos.ug_fm.10.1.1.doc/t_remap_an_object_to_a_new_source.html

But I am using Cognos FM 10.2.1 and when I right-click any of my own objects in the Project Viewer pane, I do not see any of those options listed.

Hi,

What are you right-clicking on? The "Remap To New Source" option only applies to model query subjects, and allows you to change which underlying query subject(s) they are based on.

Cheers!

MF.

[ry1633]

Yeah I just found that out. :)   All my objects are data source query subjects.   What other options do I have?   I have about 60+ objects to remap, and I really don't want to do them one at a time.

[Michael75]

What other options do I have?

XML Notepad :)   https://www.microsoft.com/en-gb/download/details.aspx?id=7973

To do a "brute force" change on your model.xml. But take a backup first!

[ry1633]

I'll try that.  I'll do a find and replace :)  (backing up the original first of course :)  )     I have Notepad ++ I can try that too.

[Michael75]

Of course, Notepad ++ can do the same thing. I just prefer XML Notepad for hacking a model.xml, due to the highly structured presentation of the data that it gives.

I don't know if they have any spies lurking here on Cognoise, but just don't tell anyone from IBM Cognos about the advice you received  8)

[bus_pass_man]

1. Select the data source connection.
2. Edit the content manager catalog and schema properties to point to your new data source connection.

If you don't immediately know those values you can import a table from the new data source, which will add the new data source to the model.
You can then select the two data source connections and you can copy the values from the new data source to the old connection.  In the enclosed png you can see it being done for the schema.   You can also just use it as reference and manually edit the original properties.


Real Soon Now I'll go through the posting about how to embedded pics into postings but not today.

[ry1633]

 bus_pass_man,

I did actually try that.  I did that exact same thing, tested the connection and published a package.   And my users said it didn't work;  they said they latest data they got from the package was May 2016 and they said they should be seeing data from this month even right up to the last week or sooner.

[Kiran P]

The only way (and easy way if you know xml) is to edit model.xml

Thanks
Kiran

[ry1633]

I'm not really opposed to editing the xml - I'm ok with that.    I worry that leaves some potential problems, like if I go on vacation and my backup person doesn't know how to do it if users need to put in for edits or fixes.  That kind of stuff.

[dougp]

If you are at all concerned about sustainability of your environment, make sure the object names (data source connections, databases, external directories for authentication, etc.) are the same across all of your environments.  That enables you to migrate content from Dev through QA to Prod without needing to remember to change code along the way.  Some organizations frown on making code changes during the move from QA to Production.

[ry1633]

If I'm editing the xml and have both data sources in my model,  can I just edit the path of the package itself to point to the other data source?  Or do I have to change that paths of everything in my model (everything in the database layer etc)?

[MFGF]

If I'm editing the xml and have both data sources in my model,  can I just edit the path of the package itself to point to the other data source?  Or do I have to change that paths of everything in my model (everything in the database layer etc)?

Hi,

I have to agree with bus_pass_man and dougp here. Manually editing XML to make changes like this for a production system is really (really really really) not a good solution. Take a look at Doug's post - he's giving you good advice. Make sure the object names are the same across all your environments rather than manually hacking XML to change names. I can't stress strongly enough how unsustainable this is!!

There are multiple experienced people telling you that you're embarking on the wrong strategy here. It's up to you whether or not you heed the advice, but honestly you should.

Just my tuppence.

MF.

[ry1633]

I had that suspicion in the back of my mind.   I don't know why my admin insisted on naming the datasource different - I'm hoping that I can convince him to keep the labels the same anyway.  He's out of the office so this will be a conversation for next week.    The other option is to make the user choose between Test and Prod environments when they launch Query Studio - by my supervisor isn't keen on that, thinking our users will make the wrong choice just as often as not.

...to be continued. :)

[dougp]

The user must already be in a Cognos environment to open Query Studio.  How can they then choose which environment to use?

[ry1633]

my organization is in a tough spot, because the Cognos Dev/Test environment is at a higher version that Prod - hence any packages developed in Dev/Test have and will fail in Prod as it stands right now.  And my organization's timeline for updating Prod doesn't seem to be a very high priority for them regardless of how hard we push for it.

In the meantime, because my division *really needs* Cognos Production soon (like yesterday), a workaround we've all decided on is to point UAT at the Prod data connection so when we get the package ready (very very soon), we can run it against Production data.

Screwy scenario I know, and sorry I can't be more specific.  But it's the best we can do right now (sigh...)

[bdbits]

This Is So Screwed Up. Seriously, whoever is making these decisions needs to get this straightened out yesterday before you go with a live production environment.

At the risk of sounding like an echo... All of your Cognos servers need to be on the same version. The only exception I would allow is a brief-as-possible period while migrating from one version of Cognos to another. Otherwise... no excuse. Your data source names need to be the same across environments. They can point to completely differently-named databases, but the Cognos names should be the same. This allows electronic migration of content across environments without any changes. No sane IT audit would fail to condemn your transfer process, not to mention the potential for human error. And if IBM support finds out you are editing XML directly every time you transfer, you will likely be left hanging in the wind along with whatever issue you have.

Do it right, or don't do it at all. You can thank me and the others here later.

[cognostechie]

This Is So Screwed Up. Seriously, whoever is making these decisions needs to get this straightened out yesterday before you go with a live production environment.

At the risk of sounding like an echo... All of your Cognos servers need to be on the same version. The only exception I would allow is a brief-as-possible period while migrating from one version of Cognos to another. Otherwise... no excuse. Your data source names need to be the same across environments. They can point to completely differently-named databases, but the Cognos names should be the same. This allows electronic migration of content across environments without any changes. No sane IT audit would fail to condemn your transfer process, not to mention the potential for human error. And if IBM support finds out you are editing XML directly every time you transfer, you will likely be left hanging in the wind along with whatever issue you have.

Do it right, or don't do it at all. You can thank me and the others here later.

Unfortunately, not everyone thinks of doing things right. I have worked for companies where the IT leaders had the philosophy - 'We understand the best practices but our environment is different and we can't follow those here'. This was the excuse given for doing things in a haphazard manner because the motto was - 'Let's just do what we need right now, whatever works for now is fine and we will worry about other things later on'. The one common factor I found in all such companies was that the leaders got their jobs because of who they knew there, not what they knew.

The user must already be in a Cognos environment to open Query Studio.  How can they then choose which environment to use?

You can define multiple connections to the same data source, one pointed to DEV, another to PROD. When the user runs the report, they will get prompted to choose one of them unless security is set on those connections and they are allowed access to only one of them.

[ry1633]

hey guys,  I'm right there with you.  I don't like how it is set up in my org, but I had no control over how it was set up (lack of correct versions between environments), and so I'm kinda stuck working in a less-than-ideal environment.  I don't like it, but I also can't help it.

[bdbits]

I hope you did not take it personally. Sometimes I get really annoyed with sub-optimal processes that should not have to be that way, and end up sounding like a crabby old guy. I am old, but try not to be crabby.  :-[

Hopefully at some point, the dunderheads will gain enlightenment or perhaps leave, and you can make it right. Oops, there I go again...  :D

[ry1633]

yeah sometimes its hard to make lemonade when you have either bad lemons, or no lemons at all :)   Oh well,  this is the situation I'm in, I'm just trying to make the best of it.   And will make every effort to not have to go through this on the next Cognos project I do after this one.