Persistent Feeder query

[Steve Rowe]

I had an interesting experience "at" a client site on Friday, running PAL 2.0.92.19., the initial build of the application having been done by a third party. (apologies for the long post, btw)

We were getting some mysterious behaviour on the feeder side of the model and had established that a feeder for a particular rule was missing but the rule was partially working because of flags in a persistent feeder file.

Sequence of events as follows with Persistent Feeders on.

1. Feeder written and saved, the right hand side of the feeder contains a lookup to redirect depending on the left hand side. The lookup cube was incorrectly populated in some cases. For those cells where the lookup cube was correctly populated the feeder worked and for those that weren't the feeder didn't. As expected.

2. Lookups corrected and feeders recompiled via, resaving (rules invalidated to trigger feeder compile), via TI command and by unloading and reloading cube. None of these steps corrected the feeder, only the cells correctly fed in step 1 worked.

3. Using Trace feeders indicated that the destination cells were fed in all cases. (though this only displays what should be happening, not what actually did happen at compile time.)

4. We deleted the .feeder file on disc (without restarting) and recompiled the rules. .feeder file rebuilt but the newly introduced feeder statement was not working at all, i.e. both the working and not-working from step 1 were failing.

5. We tried various forms of the feeder including a single explicit fully qualified cell on the left to the destination, none of these worked although they all showed up in the trace feeders with multiple traces showing up for each of the various ways we wrote the feeder.

6. We entered a new value in the feeder source, changing a null (0 in the cube viewer) to a value. The feeder correctly triggered for that cell.
7. A stop of the DB, deletion of the .feeder file adnd then DB start corrected the issue.

8. We've not had chance to test the behaviour with persistent feeders off.

9. We also checked the rule .blb for any differences, there weren't any.

Conclusion.
A. The feeder was written correctly or 6 would not have happened.
B. Feeders were firing for new data points
C. The recompile of feeders for existing data was failing but apparently only for the new feeders (or the .feeder file wouldn't get being rebuilt).

Query.
My view is that we've hit a defect but I just want to sense check if the above could be considered expected behaviour of persistent feeders.

[PavoGa]

Steve, I ran into the same problem about two weeks ago. We use persistent feeders as well. Observed and did the same things you did in resolving.

Question on your case: are any of the rules referencing alternate hierarchies?

[Steve Rowe]

Not that I am aware of but I will double check.

Did you raise a defect? Or just turn Persistent Feeders off?

[Steve Rowe]

There is one dimension that has hierachies common between both source and target cube.

They are not referenced in the rules and definitely not in the problem area, so in theory it is the N level only.

Something we didn't check was if the numbers were working in PAW or versus a different hierarchy, checking was in legacy cube viewer.

[PavoGa]

Not that I am aware of but I will double check.

Did you raise a defect? Or just turn Persistent Feeders off?

Steve, sorry, I went back and reviewed my notes. I conflated an issue we had a couple of weeks ago which was a perfectly normal and expected feeder behavior vs. the problem with feeding to and/or from alternate hierarchy leaf elements, which has already been raised and does affect feeder behavior. And yes, we did raise that one with IBM as a defect. You should be familiar with it as you commented on it.

My apologies on the confusion there.