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] – ↷ Links adapted because of a move operation localdev2000_concepts:0600_data_retrieval:0100_config_queries [2026/08/13 07:20] (current) – external edit 127.0.0.1
Line 33: Line 33:
 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]]. 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 [[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]]).</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 49: Line 55:
  
 See also [[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 =====