Updated RUX files not recognized in 10.1.1?

[blackhawk]

I just ran into a strange situation in migrating from QA to PROD that I wanted to check with others to see if they have noticed this as well.

Over the last 20 years of working with TM1 (man I feel old!), I have always migrated rules and processes from server to server by copying the files. Last night however, the rule files I copied from QA to PROD were not being picked up despite shutting down servers, updating timestamps, etc. It turned out to be that rule BLB files were being created and used on server startup rather than the RUX files.

Anyone see that kind of behavior or was it just me loosing it during the 2am migration?

[lotsaram]

Yep. If there is a blb then it gets picked up instead of the rux. I always run a bat to delete all blb files for this reason when doing any copying of rux files.

[tomok]

It's always been that way, the .blb files, if they exist, take precedence over .rux, and this always trips people up. I always turn off the Advanced Rules Editor (the .blb files contain the stored formatting) just for this very reason, thus I don't have to deal with it anymore.

[Duncan P]

I seem to get them with just the standard editor. I wonder what I am doing wrong.

[lotsaram]

As far as I've seen the blb files are generated with or without the advanced rules editor. In fact I would have thought the blb files were unnecessary with the advanced rules editor since it applies its own non editable code formatting standards. whereas in the plain text editor you can have your bold and different font sizes and colours if you really want to.

[Harvey]

I always format my rules in Courier New, to make the text monospace and more readable. I can confirm this always generates blb files, which can be frustrating when doing a file-copy deploy.

I used the Advanced Rules Editor for about 30 minutes before turning it off and leaving it off forever, so I don't know if that generates blbs.

[blackhawk]

I have never seen an updated rux ignored over a blb until few days ago. Hmmmm.....going to have to investigate this a bit deeper.

[lotsaram]

Whether the blb version of the rule is actually attached to the cube vis a vis the rux version I don't know. If this is the case then it is a major freakin defect as opposed to a mere bug. I do know for certain that when opening the rules editor it is the blb copy that takes precedence and that alone is sufficient for me to always delete the blb files just in case.

[Harvey]

I just did a test. I started a server and saved a rule with some font settings. The blb was created. I shut down the server, then manually edited the RUX file in a text editor, without changing the blb.

When I re-started the server, the rule that appeared in the editor was the unedited rule -- ie, it picked up the blb version to display. However, the calculation logic itself came from the updated RUX file. If I clicked save without editing, the updated rule continues to apply. However, if I type so much as a space and click save, of course the old (blb) rule overwrites the updated one.

So, as lotsa said, that's enough for me to blow away all the blbs when deploying to production, as the last thing you want is for someone to go into the rule editor and see an old rule that is not even applied to the model -- let alone that they might decide to save that rule, which would overwrite the updated one!

[Michel Zijlema]

I just did a test. I started a server and saved a rule with some font settings. The blb was created. I shut down the server, then manually edited the RUX file in a text editor, without changing the blb.

When I re-started the server, the rule that appeared in the editor was the unedited rule -- ie, it picked up the blb version to display. However, the calculation logic itself came from the updated RUX file. If I clicked save without editing, the updated rule continues to apply. However, if I type so much as a space and click save, of course the old (blb) rule overwrites the updated one.

So, as lotsa said, that's enough for me to blow away all the blbs when deploying to production, as the last thing you want is for someone to go into the rule editor and see an old rule that is not even applied to the model -- let alone that they might decide to save that rule, which would overwrite the updated one!

Jumping in a bit late here... This is no new behavior - I'm pretty sure this has been the behavior ever since the rule formatting .blb files were introduced. The rules editor opens the .blb file, but the server applies the .rux file. Tricky indeed.

Michel