Support Forum

[ECRStevens]

Hello,

We're experiencing inconsistencies between different accounts for cached calculated fields. Two different accounts looking at the same task, will show different values for the cached calculated fields. Upon edit/saving everything gets calculated correctly, but we have too many Tasks to touch every single one. I wrote a script using the SOAP API to update every task of one type, but it only resolved the issues for myself, others are still seeing incorrect values.

The incorrect calculated values appear to be coming from other tasks.

The first occurrence of this issue (that was noticed) was on a very minor scale earlier this week where a couple people started seeing inconsistencies, on a very minor amount of tasks, but when most others viewed the task it was correct.

Then we had to perform a TrackStudio Database recovery, and since then, the issue has been widespread.

1. I have some understanding why the Database Recovery would cause this, but I'm very curious to why it was occurring before the recovery.
2. I'm also curious how to fix the issue. We are considering clearing the index directory, would that fix it? Is that the only way?

(Version: TrackStudio 5.0.2.20141113)

Thanks,
Eric Stevens

[admin]

Hello, Eric

Caching means that after field value calculated first time, it stored in the memory and used later, until someone else change this task or add message. So you shouldn't use cached fields which value depends on user, current time, other tasks content, etc.

Regarding Database Recovery - what exactly do you mean ?

Regarding deleting index directory content - you can do it, but this will affect search only.

[ECRStevens]

Hello again,

I want to explain the problem better, so let's ignore the database recovery at this point since we saw this issue both before and after.

1. We have "Route" task, which has a cached calculated field which computes a String based on fields of other tasks which have been added to the Route Task.
(In your last post you said to not do this based on other tasks content, but we currently are, and we know we need to edit/save the Route Task if information has been changed in one of the other tasks that the calculated field is looking at. These values are static, they aren't time or user dependent )

2. What we don't understand is, once that cached calculated field is showing the correct details for ONE user, it isn't always showing the correct details for ALL users.

3. Sometimes in fact, The "Route" task's cached calculated field is showing information form tasks that haven't even been added to the Route Task. It's like it is showing the cached calculated field of a different Route Task.

4. For each user that sees the information wrong, they can click edit/save and then the cached calculated field updates for them.

5. The main problem is we have too many tasks, and too many people, they can't all edit/save every task to make sure it is showing the correct value.

6. Why are different users seeing different values for cached calculated fields, shouldn't there are only be 1 cached calculated value, or does each user have their own cached values? How could we get everybody seeing the same calculated cached values. When we re-indexed Track Studio, it seemed to fix the issue but reports of inconstancies are cropping up again and we just re-indexed last week.

[admin]

It seems like it works as defined. We have per-user cache of calculated custom fields, so each field cached per user, so different users can see different cached values for the same task. Please try to disable caching for this custom field.

For old trackstudio versions interpreted calculated custom fields was very slow, new versions should run them fast. Compiled scripts should be fast everywhere.

[hammj]

Here is a simple example that might explain how we are using the calculations.

TaskA (main task)
custom field 1 (Link to Task1)
custom field 2 (Link to Task2)
custom field 3 (calculated field concatenates Task1.calcVal + Task2.calcVal, so it should evaluate to "Trackstudio Rocks")

TaskB (main task)
custom field 1 (Link to Task3)
custom field 2 (Link to Task4)
custom field 3 (calculated field concatenates Task3.calcVal + Task4.calcVal, so it should evaluate to be "Others Not so much")

Task1 (task used in the calculation)
custom field calcVal="Trackstudio"

Task2 (task used in the calculation)
custom field calcVal=" Rocks"

Task3 (task used in the calculation)
custom field calcVal="Others"

Task4 (task used in the calculation)
custom field calcVal=" Not so much"

But some users will see "Trackstudio Rocks" as the calculated value for TaskA and some see "Others Not so much". The only way they are able to get it to show "Trackstudio Rocks" in TaskA is to edit and save TaskA.

I just wanted to make sure you understood the symptoms, as I wouldn't imagine that would be the expected result.

[admin]

Ok, a few questions:
1) Do your calcVal custom fields never change after filling ?
2) Am I correct, that some users see not previous values for custom fields (before update, for example), but values from other tasks ?

[hammj]

1) Do your calcVal custom fields never change after filling ?
2) Am I correct, that some users see not previous values for custom fields (before update, for example), but values from other tasks ?

Depending on the interpretation of question 1.
1a. The calcVal field does change after editing and saving, and that is how we have been forcing them to fix themselves.
1b. For the most part these are static values that may only need to be changed once in a long while (once a year or so). But right now as we are building and populating them they will be changing a little more often.

2. Yes users see values from tasks not related to the task they are looking at.

[admin]

Hmm, this is very strange, our cache is per-task, so difficult to say how values from different tasks can be mixed.
Can you reliable replicate this issue ?

[hammj]

No we can't really recreate it on command. When we see it again is there any specific info that you would need to troubleshoot the issue?

[admin]

Actually we need to replicate it locally, in debugger.
Why you cannot just remove "cached" option ? It become too slow ?