Scenario: I have a DP type, let's call it X and it holds two DP elements "a" and "b". There's around fifteen DP types with fairly random names which have the X DP type embedded in them, for now there's a set amount of those DP types, but in the future there might be more (other DP types can come from additional new distributed system which might be added to the entire system in the future). Basically the list of DP types which use the X DP type isn't fixed.
Task: I need to run a query (or queries) to find all DPs where the "a" equals "b" - this is easily done using a WHERE a == b statement, but for that to be usable I need to reference ".a" and ".b" in the SELECT statement and that requires the use of WHERE DPT == "###". Now this is simple for the X DP type, but becomes more complicated for all DP types where the X DP type is embedded as I'm not necessarily sure how many there is.
Question: Is there a way to somehow return the amount of DP types which have another DP type embedded? or maybe run the query to fulfill the task above but without having to state the DPT?
embedded DP types in queries
- buec
- Posts:28
- Joined: Tue Dec 07, 2010 3:09 pm
Re: embedded DP types in queries
Have a look at the function dpGetRefsToDpType. It may help you.
- tpjctrl
- Posts:145
- Joined: Tue May 08, 2018 10:30 am
Re: embedded DP types in queries
Thanks buec!
- leoknipp
- Posts:2928
- Joined: Tue Aug 24, 2010 7:28 pm
Re: embedded DP types in queries
Why do you want to have this information in CTRL by using a query?
What is done with the result of the query?
Possibly you can solve it in a different way by using a third DP element with a DP function which does the comparison of "a" and "b" and writes the result to the extra DP element.
Then you only have to read the result to see if "a" and "b" matches.
If "a" and "b" are unique names which are not used in a other DP structure you can simply do a dpNames() to get all datapoints where "a" and "b" is defined. The function dpTypeName() returns the DP type for a datapoint.
Best Regards
Leopold Knipp
Senior Support Specialist
What is done with the result of the query?
Possibly you can solve it in a different way by using a third DP element with a DP function which does the comparison of "a" and "b" and writes the result to the extra DP element.
Then you only have to read the result to see if "a" and "b" matches.
If "a" and "b" are unique names which are not used in a other DP structure you can simply do a dpNames() to get all datapoints where "a" and "b" is defined. The function dpTypeName() returns the DP type for a datapoint.
Best Regards
Leopold Knipp
Senior Support Specialist
- tpjctrl
- Posts:145
- Joined: Tue May 08, 2018 10:30 am
Re: embedded DP types in queries
It doesn't have to be a query and actually I've used a mixture of query and some conditional logic to pull out what I need. I was just curious if it's all doable in a query.
Yes I was thinking about using a dp fct but there's a fair amount of dps where this comparison is required and I was worried this might put additional strain on the system. With say 500 dps and a dp fct on each one, would this be a significant load?
Yes I was thinking about using a dp fct but there's a fair amount of dps where this comparison is required and I was worried this might put additional strain on the system. With say 500 dps and a dp fct on each one, would this be a significant load?
- leoknipp
- Posts:2928
- Joined: Tue Aug 24, 2010 7:28 pm
Re: embedded DP types in queries
If 500 dp functions will create a significant load depends on the rate of value changes for the input parameters.
As long as the input DP elements are not set the Event Manager will not do any calculation of the DP functions.
Best Regards
Leopold Knipp
Senior Support Specialist
As long as the input DP elements are not set the Event Manager will not do any calculation of the DP functions.
Best Regards
Leopold Knipp
Senior Support Specialist