I bounced the server too-- it's been a month or so, so good to clean out the cobwebs....Code: Select all
2011-06-27 15:15:29.581 TM1.Audit.PostProcessor Error copying Scenario.dim 2011-06-27 16:15:29.489 TM1.Audit.PostProcessor Error copying Cost_Center.dim 2011-06-27 18:15:29.304 TM1.Audit.PostProcessor Error copying Scenario.dim 2011-06-28 09:15:29.494 TM1.Audit.PostProcessor Error copying Scenario.dim
Classic.The reason for the mesages is that you will have had more than one process making a change to the same dimension within one minute.
What is happening is that after the dimension change process finishes an audit process runs to record these changes. This audit process wakes up every minute to process all the auditing for the preceding minute. It sees the first dimension change and writes a file Scenario.dim.<timestamp> it then sees the second change to the same dimension and again tries to write another file Scenario.dim.<timestamp>. If when it tries to write the second file, for the second dimension change, the timestamp is the same as the first it will fail to write it as it already exists. The issue is that the timestamp is only calculated to the second.
The dimension change itself is not affected only the audit trail is affected.
The recommended way to avoid this happening is to try and separate dimension changes that change the same dimension by more than a minute.
I know! I should really plan all of my TI scripts to work as if they were a human hand-calculating the data to accommodate logging. WTF.Mike Cowie wrote:Apparently you just work at too high a rate of speed... multiple dimension updates in under a minute!