Assign new IDs during import?

[Bergstrand]

Hi,

I am looking in an instruction for deploying from our Cognos dev environment to test and prod. On import to test and prod it says to check "Do not assign new IDs during import" but does not give an explanation why. What could be the reason for not assigning new IDs when importing a package (overwriting an existing package)?

For example, I am deploying a changed package to production; do all existing reports refer to the package by ID and will they thus not work if a new IDs is assigned to the package?

Thanks!

[bdbits]

Yes, Cognos sometimes, but not always, use an object ID rather than the object name link things together. Packages are an example of something referenced by ID. If you are updating a package already in use, you do not want a new ID or you may break things that reference it.

[Andrew Weiss]

My understanding is that IBM Cognos has 2 ways to identify an object: SearchPath & StoreID

Search Path is designed for long term use (e.g. SDK, URL Api, Storing information) where as StoreID is designed for short term use within a cognos session. Objects in Cognos reference other objects using both properties, (e.g. reports to a package, shortcuts to any object, reportviews to reports, job steps).  By using both properties Cognos can find the object by one or the other. 

SearchPath is based on the XPath query language and is location based.  Which means if you move the object the SearchPath will change.  The search path is more "readable" and describes where the location of the object is. For example: /content/package[@name="Go Sales"]/report[@name="Add Color"]. SearchPath is preferred for integrations because it points to the object in the location that you're looking for and does not rely on StoreID which can change.

StoreID is a GUID (without the dashes) and looks like a string of letters and numbers.  The storeid is assigned to the object, is unique and does not change (except during export/import). 

If you Cut and Paste an object to a new location the SearchPath will change but the storeID will not.  This is a Move operation and Cognos will update all referenced objects to the new searchpath. 

If you Copy and Paste an object to a new location the object will get a new searchpath and a new storeID.  This is why you never copy / paste an object then delete the original.  That's not a move and you'll break everything that references it. 

Now for the export/import.  It used to be (I believe) that Cognos said, don't use storeid except within a session because it can change and you can't trust it over time or beyond the session.  We didn't all get the memo and started using storeid in places like links to cognos viewer, SDK applications and so on.  Now after an export/import where the storeids DO change all of our integrations break.  So Cognos added the option to retain the IDs, with the caveat that they still have to be unique, so if a collision is encountered then the object will likely get a new ID.  Note that these IDs are guids so you don't need to worry about that (Google guid uniqueness and you'll see their explanation).

So with the explanation out of the way, my understanding is that you really only need to check this box if you've developed something and specifically used a StoreID to reference an object.   Reports that are tied to packages, shortcuts and other references will not break if this box is unchecked.

Thanks!
-Andy

[Bergstrand]

Thank you both for clearing this out!

[irvingbos]

Hi, the setup of Application Drill Throughs in Active reports REQUIRES the Store ID to be entered. Does this change the discussion  of how and how not to keep Store IDs intact when performing export-imports? Also, i find the terminology confusing "assign new IDs" means to "retain the Store ID of the object in the TARGET system"  (the one to which you are deploying).

[cognostechie]

Hi -

Assigning new IDs during import has nothing to do with the IDs of the database. The Store-ID is your ID from the database. It's a valid value in your data. What Cognos is referring to is the IDs it assigns to it's objects internally inside the Content Store. I have always selected the option to assign new IDs and it has always worked regardless of whether I am deploying reports or packages. The only time you would need not to assign new IDs is when you would want to archive the earlier report output somewhere. If your goal is to replace the earlier report with the new report/package then assigning new IDs is recommended.