I have a client testing a model on a local server and they are getting totally different results for consolidations on a local server than I see when running it as a remote server. I have checked here and see the same difference. 9.1 SP2 U3
I am guessing that this has to do with the AllowSeparateNandCRules=T TM1S.cfg setting, which if i recall doesn't get read when you start a local server (of course not - why would you want a local server to behave the same way? )
Anyway - if anyone can confirm that this is expected it would be very helpful.
Ages ago when we used 8.1.8 i remember seeing local servers with different numbers to that of a "real" server. We've never used local servers since, its just not worth the aggravation
If this were a dictatorship, it would be a heck of a lot easier, just so long as I'm the dictator. Production: Planning Analytics 64 bit 2.0.5, Windows 2016 Server. Excel 2016, IE11 for t'internet
Config file parameters are ignored for local server so there will inevitably be some discrepancies in behaviour.
HOWEVER if you are specifically seeing discrepancies in calculation results due to the use of AllowSeparateNandCRules=T then surely the the simple solution would be to shake your old dinosaur bones and re-write the rules to post version 7 syntax!
That is rather than this
['Area'] = N: .... ;
['Area'] = C: .... ;
The example you have given is really a special case where the LHS of the N and C part are the same, it's usually not as simple, though.
[AreaA]=N:
[AreaB]=C:
AreaA and AreaB partially overlap in some way. You then have to specify additional Ifs in your C level rule for AreaA where A and B intersect, potentially even adding attributes to the system in order to be able to do this.
[AreaA]=N:
C: If ( AreaA is a member of AreaB, blah, stet);
[AreaB]=C:
Giving a more complex set of rules
That change in syntax when it was introduced really added nothing (unless a non-AllowSeparateNandC server runs faster?) and just made writing rules harder by introducing restrictions on what the LHS could talk about. Never really saw the point. I don't really think that it's a case of this being an "old fashioned approach", it's more a case of it being a more practical way of writing rules.
Irrespective of that, it doesn't seem sensible that a local server should ignore the cfg parameters. Maybe you could argue it's a license thing, since local/perspective servers are intended as single use stand alone servers, so why would you want all the cfg stuff. If you need a development server buy a development license. Who knows what was going in the Applix corporate brain!
Cheers,
I would say that mostly, if not almost always, that separate N and C rules do apply (or can be made to apply) to the same cube area. Normally this is in a budgeting/planning type scenario where at N level you have something like volume and price per unit. At N level unit price, COGS, GP, etc. is an input or lookup from another cube whereas at C level you need to monitor the effects of product mix on margin and need to calculate average price per unit and mix effects.
This might be over-simplified, but in dozens of TM1 models across a variety of industries I am yet to see a separate N and C rule that could not be combined into a single area statement. I'm not saying that such situtions don't exist, only that it is extremely rare in practice to require a true multidimensional calculation with overlapping areas over N and C cells.
Where such a requirement does exist it could usually be solved by splitting out to more discrete area statements. If anyone has an example where separate overlapping N and C rules are the only viable option I would be really interested in those examples.
I agree on your comments about about local servers & config parameters, probably more than a grain of truth in those aspersions.
Hi lotsa!
Debate rules, especially before you've had your first coffee!
As ever with TM1 you can make it do what you want how you want.
I just feel that being forced to write the N and C in exact area pairs is unnecessarily restrictive and does not seem to bring any benefits at all. If putting the NadC para in slowed TM1 down by 10% then a case could be made for not using it.
Anyone done any testing or noticed any benefits of not using the parameter? When building a new application it's usally the first thing I put in the cfg file. Hope they never stop supporting it.....
Altough you can achieve the same rule by using complex conditional rule statements using ISLEAF and DTYPE functions, I agree that using AllowSeparateNandC=T gives extra flexibility and freedom in writing rule statements for overlapping area definitions.
)
