This seems pretty standard SQL. We have other expression that are way more complex.
Cannot figure out what this error means. Any ideas?
What is âHEADâ? I think you need to define that better. Normally I use Case When. Im not sure what the syntax you pasted is supposed to do.
3 Likes
Iâve always seen it where Case When is together, more like the below:
(CASE
WHEN HEAD - Other.MinThkOvrride = 0 THEN HEAD - OTHER.MinThkCalc
ELSE HEAD - Other.MinThkOvrride
End)
2 Likes
yeah that my norm too but both are valid - this is how the functions template does it so it tried it their way. 
Itâs just an alternate way to write it. It can reduce repetition and keep it âsimplerâ, but for anything more convoluted than a single check youâll end up reverting to Case When.
Example:
CASE PartPlant.Plant
WHEN 'Plant1' THEN '1'
WHEN 'Plant2' THEN '2'
WHEN 'Plant3' THEN '3'
--etc
ELSE ''
END
instead of
CASE
WHEN PartPlant.Plant = 'Plant1' THEN '1'
WHEN PartPlant.Plant = 'Plant2' THEN '2'
WHEN PartPlant.Plant = 'Plant3' THEN '3'
ELSE ''
END
2 Likes
the Dyn Class is called âHEAD - OTHERâ so real SQL would be like
[HEAD - OTHER].[MinThkOverride]
but how itâs shown is how they want it - works on other calcs, doesnât work with brackets.
Way over my head! Let us know what you figure out!
1 Like
Meanwhile this one works great. 
Thought it may be because Iâve referenced and calculated attribute in another calc but that doesnât appear to be the problem and Iâm pretty sure Iâve done so before.
FYI - This is a calculated attribute of a Dynamic Attribute Class. It calulates the Minimum Thickness of a dished vessel head (round end of a tank) using a matrix of thinning factors by diameter/thickness.
Much like any BAQ calculated field except the Dynamic Attribute Class name is used in expressions as if a table name.
1 Like
Turns out their self-reference checker is poorly done.
For setting attribute named HEAD - OTHER.MinThk
this works fine:
CASE HEAD - OTHER.OverrideMinThk
WHEN 0 THEN HEAD - OTHER.CalcMinThk
ELSE HEAD - OTHER.OverrideMinThk
END
while this doesnât (notice HEAD - OTHER.MinThk exists in HEAD - OTHER.MinThkCalc)
CASE HEAD - OTHER.MinThkOverride
WHEN 0 THEN HEAD - OTHER.MinThkCalc
ELSE HEAD - OTHER.MinThkOverride
END
presumably because they do a simple check to see if the string HEAD - OTHER.MinThk exists in the expression. Rather than also ensure itâs followed by a space or another character to avoid false positive matches.
Pretty sure BAQ calculated expressions donât do this poorly. or if they do I suppose the forced âCalculated_â prefix avoids false positives in BAQs.
I have to ask why you decided to go with multiple whens instead of using IN. Personal preference or is there a functional gain? Something like this.
CASE
WHEN HEAD - OTHER.NomThk IN (0.1050, 0.1200, 0.1350, 0.1870, 0.1875, 0.2500, 0.3125)
THEN 0.0625
ELSE 0
END
1 Like
Good question, maintainabilty is all. The matrix is used across several classes and can differ across Suppliers. Decision makers were undecided, so I made the expression atomic for those reasons. They can easily change a thinning factor without considering SQL logic.
Plus, some are not as straight-forward as others.
1 Like