GetPoints Syntax

       

 

The GetPoints method can be used to retrieve PIPoints and PointAttributes from a PI3 server. The method always returns a PointList and updates the internal PointAttribute collections/cache with the requested attributes. GetPoints can be invoked directly by the user (Server.GetPoints method) or indirectly by using  IGetPoints2.GetPoints2 method, basic tag-search (Basic Search tab in the dialog) or IPointAttributes interface method of the PointList collection.

 

Syntax and examples

 

The syntax is SQL-like without advanced features and with important differences that make GetPoints statements incompatible with true SQL (GetPointsSql). The basic syntax is as follows:

 

Select [attribute-list] from PIPoints Where [where-clause]

 

The caller supplies the parts inside the brackets, that is, the optional attributes and the where-clause (without the "where"). The where-clause is composed of one or more point attribute value comparison operators and simple logical operators between them. The support for logical groupings (use of parenthesis) is very rudimentary and can be applied to OR operands only.

 

 

Comparison operators: =, <>, <, >, <=, >=

 

Logical OR : Any number of ORs can be included in the where clause (see remarks below).

 

Logical AND : Any number of ANDs can be included. Note that it is not possible to use the same attribute (name) twice, i.e. pointid < 10 AND pointid > 5 is illegal.

                    Grouped operands are not supported, e.g. (a=0 OR b=0) AND c=0 is illegal.

 

Examples:

  1. Single operator:
    tag = 'sin*' , tag = 'sinusoi?' , pointtype < 10 , descriptor <> '' (not empty)
  2. Logical OR:
    tag = 'sin*' OR tag = 'tot??' , location2 = 10 OR tag = 'a*'
  3. Logical AND: tag = 'sin*' AND location2 = 10 , descriptor <> '' AND pointsource = 'R'
  4. Legal Combinations:
  5. Illegal Combinations:

    Remarks

    In theory, users can include any number of ANDs and ORs in the where-clause. However, using one or more ORs or combinations of ANDs and ORs is problematic and should be avoided if possible. The problem occurs if the first processed operand (or either one of the AND operands) meets the following conditions:

    If all these conditions are true, the query optimizer will ignore the remaining conditions/operands and returns incomplete data. This situation is difficult to detect because the call completes successfully but with wrong set of points.

    Note: This behavior is not by design, it is caused by an error in the server code. The problem will be fixed in future releases of the PI3 server.

    Examples:

    1. pointsource='L' OR tag='sinu*'
      Exact match on pointsource (tag='sinu*' OR pointsource = 'L' would work properly).
    2. (pointsource='R' AND tag='sine*') OR (pointid < 10 AND tag='sin*')
      Exact match on pointsource (swap the OR operands to correct the problem).
Enabling Operational Intelligence