ForceSkipCheck ?

[lotsaram]

Hi All,

I just came across an oddity in the 9.5.2 documentation which I can't find any reference to prior to 9.5.2:

http://publib.boulder.ibm.com/infocente ... eders.html

ForceSkipCheck
Forces the query to perform as if the cube had a SKIPCHECK in the rules. This means that the query will process only values actually in the cube, as opposed to (the no SKIPCHECK case) where every possible cell would be enumerated looking for values.

This function sets the state of the view query to select only values in the cube. The function must be added to the Prolog section of the Turbo Integrator process. By placing the ForceSkipCheck() in the Prolog it effects the entire view query of data elements to follow.

Syntax
ForceSkipCheck()
There are no arguments for this function.

My interpretation is that ForceSkipCheck() needs to be used in conjunction with ViewExtractSkipZeroesSet(Cube, ViewName, 1) in order for ViewExtractSkipZeroesSet to produce the desired or expected behaviour even where rules may have been implemented without SkipCheck.
Is that your take also?
Presumably this was introduced as an enhancement because someone out there requested it ... Does anyone have any experience with actually using this function? Does it do what is says on the can?

[tomok]

My interpretation is that ForceSkipCheck() needs to be used in conjunction with ViewExtractSkipZeroesSet(Cube, ViewName, 1) in order for ViewExtractSkipZeroesSet to produce the desired or expected behaviour even where rules may have been implemented without SkipCheck.
Is that your take also?

I hadn't noticed this new function but your interpretation is the only situation where I could see it being necessary.

[rmackenzie]

A quick test seems that the command is useful when you want to exclude rule-derived values from the extract - by forcing the Skipcheck they become unfed and thus are excluded from the view.

My interpretation is that ForceSkipCheck() needs to be used in conjunction with ViewExtractSkipZeroesSet(Cube, ViewName, 1) in order for ViewExtractSkipZeroesSet to produce the desired or expected behaviour even where rules may have been implemented without SkipCheck.

An extract view is, by default, set to skip zeroes - you wouldn't need to state ViewExtractSkipZeroesSet(Cube, ViewName, 1)... am I missing what you meant? My test model (attached) indicates it doesn't make a difference whether you include this statement or not. On the other hand, using ViewExtractSkipZeroesSet(Cube, ViewName, 0) seems to nullify the impact of ForceSkipcheck. When you say 'where the rules may have been implemented without SkipCheck' then isn't it implied that they are because of the use of ForceSkipcheck in the TI?

Presumably this was introduced as an enhancement because someone out there requested it ... Does anyone have any experience with actually using this function? Does it do what is says on the can?

I'm intruiged as to why someone requested this... obviously some people want to opt not to use Skipcheck on some cubes because either they are e.g. 2d and high density, or in some cases the rules are just damn difficult to feed. However, the interesting part is why you'd want to drop the rule-values and only process the input values... I guess this has an application with string cubes, e.g. show me the security that was manually entered and not the stuff from the rules... any other ideas?

[lotsaram]

I'm intruiged as to why someone requested this... obviously some people want to opt not to use Skipcheck on some cubes because either they are e.g. 2d and high density, or in some cases the rules are just damn difficult to feed. However, the interesting part is why you'd want to drop the rule-values and only process the input values... I guess this has an application with string cubes, e.g. show me the security that was manually entered and not the stuff from the rules... any other ideas?

It beats me. Based on your test I can't see what the use is that can't be achieved using ViewExtractSkipRuleValuesSet, the function seems redundant.