Problem with development_items table

[mizu]

Hello everyone,

I've developed a small application giving an overall look on workflow states of all contributor applications,.. It is based on ASP and this: http://www-01.ibm.com/support/docview.wss?uid=swg21344393

but,...

When running "Synchronization" and "Go to Production" processes on any Contributor model from a Contributor macro, records containing the e.List items in development_items table disappear while all of the e.List records in the nodestate table remain (And when they disappear from development_items table, the itemguid=nodeguid condition in the query is not met,..). On the other hand, when we run these processes manually, from Contributor Administration Console, all of these records remain in both tables mentioned above (As this is the normal behaviour).

According to documentation (Cognos Planning Database Administrator Guide), both development_items and nodestate tables should always contain e.List related records.. According to Cognos Support, it is not a bug until it directly affects the behaviour of the contributor application,..

I tested this behaviour both on 8.3 and 8.4 version of Cognos Planning, even tried to change various settings in the mentioned macrosteps. The results were still same - when using a macro to synchronize and GTP, the records containing displayname of e.List items disappear from the development_items table.

Does anyone knows if there is any way to fix this problem?

Can you think of any rational workaround?

Or, at least, can anyone come up with an idea how could this affect the contributor application (Among others, i went through application XML definitions and there were no evidence of a problem as it does not contain the displaynames of the objects,..)?

Thanks in advance for any help


EDIT:
i've uploaded a video showing what is happening in the database during the two scenarios mention in the post..
video download: http://pictures.mizu.sk/cognos/Example.wrf
player download: http://pictures.mizu.sk/cognos/WebExPlayer.msi

[adityashah27]

do you publish this app? in that case you can join with cy table...

[mizu]

no, neither of approximately 200 applications used by this is published,..

[mizu]

This far, i could only come out with the following solution:

- Create a temporary table in the database, that will copy the structure of the development_items table.
- Fill it initially with data from all the "healthy" applications" development_items tables.
- Create a stored procedure, that will compare the records in each Contributor database with the records in the new temporary table (this will be done on a schedule)

- If the development_items table for some Contributor application won't contain the necessary records (that actually are in nodestate table), then:
--- Find rows with such ID in the temporary table and insert them to the development_items table of that application

- If the development_items table for some Contributor application contains the necessary records (matching record in nodestate table), then:
--- Check if rows with such IDs exist in the temporary table:
----- In case there are such records, than everything is ok and there is nothing more to do
----- In case there aren't such records, it means that there are new items in the elist and the records in the temporary table will have to be updated

Can anyone give an argument, what could go wrong?