DIMIX trouble

[ioscat]

my DIMIX in TI variables can't find element, while i can find it by wildcard searching. Can't get what may be the reason. The same function in another process works properly.

[asutcliffe]

my DIMIX in TI variables can't find element, while i can find it by wildcard searching. Can't get what may be the reason. The same function in another process works properly.

So dimix is returning 0 for an element that exists in the dimension? That shouldn't happen. Maybe you can post your actual code?

[ioscat]

vTechEquipmentID= Dimix ( 'Техническое средство' , vTechEquipmentIDTemp);
it returns zero for one of vTechEquipmentIDTemp while i can find it in dimension

[ioscat]

Code: Select all

#vTechEquipmentID=attrs( 'Техническое средство',DIMNM( 'Техническое средство',Dimix ( 'Техническое средство' , '066.08.2.2.0801022204.ВЛ876ДОР')),'GUID технического средства');

#vTechEquipmentID=dimix( 'Техническое средство',attrs( 'Техническое средство',DIMNM( 'Техническое средство',Dimix ( 'Техническое средство' , '066.08.2.2.0801022204.ВЛ876ДОР')),'GUID технического средства'));
vTechEquipmentID=attrs( 'Техническое средство',DIMNM( 'Техническое средство',Dimix ( 'Техническое средство' , '066.08.2.2.0801022204.ВЛ876ДОР')),'GUID технического средства');

third string gives alias for the element and second gives 0...

[asutcliffe]

vTechEquipmentID= Dimix ( 'Техническое средство' , vTechEquipmentIDTemp);
it returns zero for one of vTechEquipmentIDTemp while i can find it in dimension

So the value of vTechEquipmentIDTemp is exactly the name of an element (or an alias)? Have you tried writing the value of vTechEquipmentIDTemp to a file using asciioutput to make sure?

[Steve Rowe]

I can't help directly put I suggest you ASCIIOutput the various bits and pieces and make sure what you think is happening really is.

I've never know DIMIX go wrong in this way.

[ioscat]

well, what should i put to text? i try to put not variable but digits and letters to formula and get no progress.

i wrote rule like dimix(.., attrs(.., elementprincipalname, aliasname )) and get zero while attrs(.., elementprincipalname, aliasname ) gives string value...

Well, how many elements are able to exist in dimension? More than 50K?

[Duncan P]

Is it possible that the name in the variable and the name in the dimension differ in case only, or are they exactly the same?

[asutcliffe]

well, what should i put to text? i try to put not variable but digits and letters to formula and get no progress.

i wrote rule like dimix(.., attrs(.., elementprincipalname, aliasname )) and get zero while attrs(.., elementprincipalname, aliasname ) gives string value...

The idea is to output to text the expressions or variables you're passing to dimix to see what they actually contain.

Actually I'm not really sure what you're trying to do. Perhaps you might want to explain?

Well, how many elements are able to exist in dimension? More than 50K?

The number of elements in the dimension isn't going to be the problem.

[Steve Rowe]

Something like this

nNum=Dimix('Dimension' , sElName);
If (nNum =0 );
Asciioutput ('DimixFails.cma' , sElName);
EndIf;

To get >0 sElName should be any valid alias (not attribute) or element principal name. (also returns >0 on subset names too but lets not got there...)

Cheers,

[ioscat]

deleted all attributes and created them again - now seems to work fine.

[qml]

Well, how many elements are able to exist in dimension? More than 50K?

Apparently it's around 2,000,000,000 elements per dimension, which is many times over being ridiculous if anyone ever gets close to that number.

[rmackenzie]

deleted all attributes and created them again - now seems to work fine.

Bit of a long shot... check your message log to see if you have any errors on start-up related to rule files. I've had issues in a number of 9.x.x versions where a rule compilation failure leads to problems with aliases. I've had the DIMIX failure and also the more common issue where DBRWs return *KEY_ERR when one of the element references is an alias. Unfortunately, I've not been able to pinpoint the issue to consistently replicate it and often the afflicted dimension isn't in the cube that has the failing rule so this is still to one to watch.