Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
2000_concepts:0600_data_retrieval:0100_config_queries [2026/08/13 00:53] – ↷ Page moved from docs:2000_concepts:0600_data_retrieval:0100_config_queries to 2000_concepts:0600_data_retrieval:0100_config_queries localdev2000_concepts:0600_data_retrieval:0100_config_queries [2026/08/13 07:20] (current) – external edit 127.0.0.1
Line 13: Line 13:
 The concept of a query in **AwareIM** includes both data search criteria and a particular presentation of the found data to the user (grid, calendar, chart, tree etc). Irrespective of the implementation the options for data presentation are for the most part the same - whether it's a standard query, a stored procedure or raw SQL.  The concept of a query in **AwareIM** includes both data search criteria and a particular presentation of the found data to the user (grid, calendar, chart, tree etc). Irrespective of the implementation the options for data presentation are for the most part the same - whether it's a standard query, a stored procedure or raw SQL. 
  
-When defining a query, the configurator has to indicate the business object, (or [[docs:2000_concepts:0200_basics:0600_business_object_groups|business object group]]) the instances of which the query will be searching. For standard queries the configurator has to either select the business object or group explicitly (if working in the Query Builder View) or provide it as part of the FIND action (if working with the Query Text View). For queries implemented as stored procedure the user has to specify the RETURN statement followed by the name of the business object or group. For queries implemented as an SQL SELECT statement, the name of the business object can be derived from the name of the table in the SELECT statement of the SQL.+When defining a query, the configurator has to indicate the business object, (or [[2000_concepts:0200_basics:0600_business_object_groups|business object group]]) the instances of which the query will be searching. For standard queries the configurator has to either select the business object or group explicitly (if working in the Query Builder View) or provide it as part of the FIND action (if working with the Query Text View). For queries implemented as stored procedure the user has to specify the RETURN statement followed by the name of the business object or group. For queries implemented as an SQL SELECT statement, the name of the business object can be derived from the name of the table in the SELECT statement of the SQL.
  
 The next step when defining a query is to indicate the conditions of search – only those instances of the business object that have attribute values matching the specified conditions will be retrieved by the query. for queries implemented as stored procedures or SQL SELECT statements, this step is done inside the stored procedure or SQL itself. For standard queries conditions of the search can be specified using Query Builder View as explained below or as part of the FIND action (if working in the Textual View) The next step when defining a query is to indicate the conditions of search – only those instances of the business object that have attribute values matching the specified conditions will be retrieved by the query. for queries implemented as stored procedures or SQL SELECT statements, this step is done inside the stored procedure or SQL itself. For standard queries conditions of the search can be specified using Query Builder View as explained below or as part of the FIND action (if working in the Textual View)
Line 31: Line 31:
 It is also possible to indicate attributes of objects related to the related objects, for example, ''Account.Owner.Company.Name''. There is no limit on the level of nesting of the related objects. It is also possible to indicate attributes of objects related to the related objects, for example, ''Account.Owner.Company.Name''. There is no limit on the level of nesting of the related objects.
  
-The configurator may indicate that instances of a business object found by a query should be sorted by a particular attribute(s) in a particular order and also indicate how these instances should be displayed in the Operation Mode – see [[docs:2000_concepts:0700_data_presentation|Data Presentation]].+The configurator may indicate that instances of a business object found by a query should be sorted by a particular attribute(s) in a particular order and also indicate how these instances should be displayed in the Operation Mode – see [[2000_concepts:0700_data_presentation|Data Presentation]].
  
-Configuration of queries is described in more detail in the [[docs:2500_config_apps:1100_add_edit_queries|Adding/Editing Queries]] section.+Configuration of queries is described in more detail in the [[2500_config_apps:1100_add_edit_queries|Adding/Editing Queries]] section.
  
-<callout type="primary" icon="true" title="note">  If a query searches for instances of business objects belonging to a business object group, the conditions of the query may only use attributes common to all members of the group (see [[docs:2000_concepts:0200_basics:0600_business_object_groups|Business Object Groups]]). When the results of such a query are presented to the user the presentation is only allowed to show common attributes of the group (see [[docs:2000_concepts:0700_data_presentation|Data Presentation]]).</callout>+<alert type="primary" icon="fa info-circle"> 
 +**note**
  
-<callout type="primary" icon="true" title="note"> It is possible to define a query with conditions that use attributes of a business object that the query is not searching for (they are also called //dynamically resolved// attributes or simply //dynamic// attributes). Consider the following query as an example:+If a query searches for instances of business objects belonging to a business object group, the conditions of the query may only use attributes common to all members of the group (see [[2000_concepts:0200_basics:0600_business_object_groups|Business Object Groups]]). When the results of such a query are presented to the user the presentation is only allowed to show common attributes of the group (see [[2000_concepts:0700_data_presentation|Data Presentation]]).</alert> 
 + 
 +<alert type="primary" icon="fa info-circle"> 
 +**note** 
 + 
 + It is possible to define a query with conditions that use attributes of a business object that the query is not searching for (they are also called //dynamically resolved// attributes or simply //dynamic// attributes). Consider the following query as an example:
  
 <code aim>FIND Account WHERE Account.OwnerName = Customer.Name </code> <code aim>FIND Account WHERE Account.OwnerName = Customer.Name </code>
Line 46: Line 52:
  
  
-Where does //**AwareIM**// find the instance of the Customer object and what happens if there are no instances of this object or if there are more than one instance? The answer to the first part of the question is that the instance is taken from the Context (this is explained in the [[docs:2000_concepts:0800_data_processing:0100_rule_evaluation:0800_context_rule_execution:0300_other_uses_context|Other Usages of Context]] section); the answer to the second part is that if //**AwareIM**// cannot find the instance of the object in the Context it logs a run-time error and the query is not run. The queries using dynamic attributes should only be used in situations where such attributes can be unambiguously resolved.+Where does //**AwareIM**// find the instance of the Customer object and what happens if there are no instances of this object or if there are more than one instance? The answer to the first part of the question is that the instance is taken from the Context (this is explained in the [[2000_concepts:0800_data_processing:0100_rule_evaluation:0800_context_rule_execution:0300_other_uses_context|Other Usages of Context]] section); the answer to the second part is that if //**AwareIM**// cannot find the instance of the object in the Context it logs a run-time error and the query is not run. The queries using dynamic attributes should only be used in situations where such attributes can be unambiguously resolved.
  
-See also [[docs:2000_concepts:0600_data_retrieval:0110_queries_user_input|Queries that Require User Input]] +See also [[2000_concepts:0600_data_retrieval:0110_queries_user_input|Queries that Require User Input]] 
-</callout>+</alert>
  
 ===== Defining Queries Implemented as Stored Procedures===== ===== Defining Queries Implemented as Stored Procedures=====
Line 60: Line 66:
 This stored procedure has two parameters - the second is hardcoded and the first one is initialized from the object in Context (ParamObject). This stored procedure has two parameters - the second is hardcoded and the first one is initialized from the object in Context (ParamObject).
  
-<callout type="primary" icon="true" title="note"> +<alert type="primary" icon="fa info-circle"> 
 +**note** 
 When a configurator defines a new **AwareIM** query implemented as stored procedure and the stored procedure already exists, a developer can initialize the new query from the list of stored procedures available in the database and generate an appropriate EXEC_SP statement. When a configurator defines a new **AwareIM** query implemented as stored procedure and the stored procedure already exists, a developer can initialize the new query from the list of stored procedures available in the database and generate an appropriate EXEC_SP statement.
-</callout>+</alert> 
 + 
 +<alert type="primary" icon="fa info-circle"> 
 +**note**
  
-<callout type="primary" icon="true" title="note">  
 **AwareIM** automatically provides support for dynamic paging, dynamic sorting and dynamic filtering of records returned by queries implemented as stored procedures. However, you need to know the following: **AwareIM** automatically provides support for dynamic paging, dynamic sorting and dynamic filtering of records returned by queries implemented as stored procedures. However, you need to know the following:
   - Support for dynamic paging, sorting and filtering is only provided for MySQL and SQL Server databases.   - Support for dynamic paging, sorting and filtering is only provided for MySQL and SQL Server databases.
Line 71: Line 81:
 %%SELECT...%%\\ %%SELECT...%%\\
 %%-- END MAIN SELECT%%\\ %%-- END MAIN SELECT%%\\
-</callout>+</alert>
  
 ===== Defining Queries Implemented as SQL SELECT Statements ===== ===== Defining Queries Implemented as SQL SELECT Statements =====