Override "Calculated" field.

[akeppel]

Question. I'm trying to calculate the "short_description" field for project tasks so it's a combination of the "top_task" and a "u_short_name" field (PJ01234 - Order Equipment), but can't set the calculation on the "task.short_description" field because it will apply that calculation to the short_description of ALL tasks (incidents, problems, catalog tasks, etc...).

I figured I'd use a dictionary-override so it just applied this calculation to pm_project_task records, which works fine...IF I have the "calculated" box checked on "task.short_description" (but then, if I do that, it calculates all short_descriptions again...)

I can't find a way to make a dictionary-override override whether or not the field is calculated. I can override what the calculation IS, but not whether or not it's calculated. If I leave "calculated" (the property is actually called "virtual") unchecked, it ignores my dictionary override calculation.

Anybody know if there's a way to override the "calculated" box in a dictionary override? I can't find mention of an attribute to set to "true" in any of the pages about the dictionary.

Andrew

http://wiki.service-now.com/index.php?title=System_Dictionary (calculated and calculation fields)
http://wiki.service-now.com/index.php?title=Dictionary_Attributes

[Mark Stanger]

One idea off the top of my head would be to go ahead and do a calculation at the task level but the calculation would just set the value to 'current.short_description'.

[akeppel]

I was hoping it would be something that simple, and coming from you it must be ok.

I just didn't know if it was kosher to perform a calculation on a field like this just so the box could be checked. Is that the way you would do it or would you try to find a way to activate that checkbox using an override?

[Mark Stanger]

I've never had to do this specifically, but that's the only way you can do it with a calculated field. You would just have to put this in the base table calculation...
current.short_description;

You could also accomplish something similar by using a default value and a 'before' business rule on your extended table. With that method, you wouldn't use the calculation at all, just perform the calculation as the default and follow up on each insert/update with the business rule just in case it got edited from what you want it to be.

If it were me, I'd try the calculation route first. The only issue I can see as a possibility is that you might encounter performance issues by running that calculation all the time on something common to a large table but I think that impact would be minimal due to the fact that the calculation is just setting the current value back into the field. If you did run into issues you could use the default/business rule alternative as a fall back.

[CapaJC]

Calculated fields are a concept I wish we'd never introduced. Their unfettered use has been the cause of more performance issues than I care to remember.

Case in point: over 5 years ago in /hi, I created a very simple calculated field on a pretty busy table to help troubleshoot a problem. The field was an integer, and the calculation was the number of characters in one field added to the number of characters in a dot-walked field. When I was done, I neglected to remove the field or disable the calculation.

While troubleshooting a tangentially-related performance issue in /hi a couple months ago, we found that this one field was responsible for over 90% of the SQL Select statements (database queries) made when viewing several record producers and change request forms in /hi. And I'm talking the difference between 800 and 8,000 SQL statements! Just 'cuz of this one calculated field. That had been doing its thing for FIVE YEARS!

Calculated fields are the devil. Also you can't sort them or query them reliably. Do what you need to do with one or more Business Rules instead. e.g., if you want a calculation on Problem of the number of child Incidents, put a Business Rule on Incident instead to modify the Problem field when appropriate.