You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: powerapps-docs/developer/data-platform/best-practices/business-logic/implement-all-types-of-queries-when-filtering-preoperation-retrievemultiple.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -78,7 +78,7 @@ Unified Interface replaced the legacy web client for model-driven apps. Unified
78
78
[Sample: Modify query in PreOperation stage](../../org-service/samples/modify-query-preoperation-stage.md)<br />
79
79
[Query data using the SDK for .NET](../../org-service/entity-operations-query-data.md)<br />
80
80
[Query data using FetchXml](../../fetchxml/overview.md)<br />
81
-
[Build queries with QueryExpression](../../org-service/build-queries-with-queryexpression.md)<br />
81
+
[Build queries with QueryExpression](../../org-service/queryexpression/overview.md)<br />
82
82
[Limit the registration of plug-ins for Retrieve and RetrieveMultiple messages](limit-registration-plugins-retrieve-retrievemultiple.md)<br />
Copy file name to clipboardExpand all lines: powerapps-docs/developer/data-platform/best-practices/work-with-data/retrieve-specific-columns-entity-via-query-apis.md
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -144,8 +144,8 @@ Queries submitted to retrieve data from Dynamics 365 should not select all colum
Copy file name to clipboardExpand all lines: powerapps-docs/developer/data-platform/fetchxml/aggregate-data.md
+1-10Lines changed: 1 addition & 10 deletions
Original file line number
Diff line number
Diff line change
@@ -231,16 +231,7 @@ The following example returns the number of related accounts in a column named `
231
231
</fetch>
232
232
```
233
233
234
-
## Limitations
235
-
236
-
Queries that return aggregate values are limited to 50,000 records. This limit helps maintain system performance and reliability. If the filter criteria in your query returns more than 50,000 records, you get the following error:
237
-
238
-
> Number: `-2147164125`
239
-
> Code: `8004E023`
240
-
> Message: `AggregateQueryRecordLimit exceeded. Cannot perform this operation.`
241
-
> Client error message: The maximum record limit is exceeded. Reduce the number of records.
242
-
243
-
To avoid this error, add appropriate filters to your query to make sure it doesn't evaluate more than 50,000 records. Then run your query multiple times and combine the results. Appropriate filters depend on the nature of your data, but they could be a date range or a subset of values in a choice column.
Copy file name to clipboardExpand all lines: powerapps-docs/developer/data-platform/fetchxml/filter-rows.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -162,7 +162,7 @@ You can create filters that compare columns on values in the same row using the
162
162
</fetch>
163
163
```
164
164
165
-
### Cross table comparisons
165
+
### Cross table column comparisons
166
166
167
167
With FetchXML only, you can compare field values in related tables. The following example returns rows where the contact `fullname` column matches the account `name` column.
Copy file name to clipboardExpand all lines: powerapps-docs/developer/data-platform/fetchxml/optimize-performance.md
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -27,7 +27,7 @@ If you select many lookup and computed columns, and you're experiencing performa
27
27
Using the `latematerialize` attribute might not always provide a performance benefit. It might make simple queries run more slowly. It's most beneficial when your query:
28
28
29
29
- Has many joins
30
-
- Contains many columns lookup columns or computed columns
30
+
- Contains many lookup or computed columns
31
31
32
32
## Query Hints
33
33
@@ -37,7 +37,7 @@ Using the `latematerialize` attribute might not always provide a performance ben
37
37
Microsoft SQL Server supports many query hints to optimize queries. FetchXML
38
38
supports query hints and can pass these query options to SQL Server using the [fetch element](reference/fetch.md)[options](reference/fetch.md#options) attribute.
Copy file name to clipboardExpand all lines: powerapps-docs/developer/data-platform/fetchxml/order-rows.md
+4-96Lines changed: 4 additions & 96 deletions
Original file line number
Diff line number
Diff line change
@@ -130,110 +130,18 @@ The data contained by most column types is relatively simple and you can perform
130
130
131
131
When you order using lookup columns, the results are sorted using the primary name field for the related table. The database stores a GUID value. The [formatted value](select-columns.md#formatted-values) returned is the corresponding primary name field.
132
132
133
-
### Choice Columns
133
+
### Choice columns
134
134
135
135
Choice column values are also sorted using the [formatted values](select-columns.md#formatted-values) rather than the values stored in the database. Data for these columns are stored as integers. The formatted value is a localized label based on the user's language.
136
136
137
-
This behavior can be overridden by setting the [fetch element](reference/fetch.md)`useraworderby` (*Use Raw Order By*) boolean attribute. When this attribute is set, all sorting of choice columns will use the integer values instead.
138
-
139
137
> [!NOTE]
140
138
> Since choice sorting is based on the localized label of the users's language, expect different ordering for the results set if the user's language differs.
141
139
142
-
## Ordering and paging
143
-
144
-
How a page is ordered makes a big difference when paging data. If the information about how the results are ordered is ambiguous, Dataverse can't consistently or efficiently return paged data.
145
-
146
-
Add an order element to your query. If you don't add any order elements to your query, Dataverse adds an order based on the primary key of the table. However, when your query uses the `distinct` attribute, no primary key values are returned, so Dataverse can't add this default order. You must specify a paging order. Without any order specified, `distinct` query results might be returned in random order. [Learn more about returning distinct results](overview.md#return-distinct-results)
147
-
148
-
Paging is dynamic. Each request is evaluated independently as they're received. A paging cookie tells Dataverse the previous page. With this paging cookie data, Dataverse can start with the next record after the last one on the preceding page.
149
-
150
-
Paging works best going forward. If you go back and retrieve a page you previously retrieved, the results can be different because records could be added, deleted, or modified during since you last retrieved the page. In other words, if your page size is 50 and you go back, you get 50 records, but they might not be the same 50 records. If you keep progressing forward through the pages of a data set, you can expect all the records are returned in a consistent sequence.
151
-
152
-
### Deterministic ordering is important
153
-
154
-
*Deterministic ordering* means that there's a way to calculate an order consistently. With a given set of records, the records are always returned in the same order. If you need consistent orders and paging, you must include some unique or semi-unique column values and specify an order for them to be evaluated.
155
-
156
-
#### Nondeterministic example
157
-
158
-
Let's look at an example that is *nondeterministic*. This data set contains only **State** and **Status** information and is filtered to only return records in an open **State**. The results are ordered by **Status**. The first three pages are requested. The results look like this:
159
-
160
-
| State | Status | Page |
161
-
|-----------|------------|---------------|
162
-
| Open | Active | 1 Start |
163
-
| Open | Active | 1 |
164
-
| Open | Active | 1 End |
165
-
| Open | Active ||
166
-
| Open | Active ||
167
-
| Open | Inactive ||
168
-
| Open | Inactive ||
169
-
170
-
The paging cookie saves information about the last record on the page. When the next page is requested, the last record from the first page isn't included. However, given the nondeterministic data, there's no guarantee that the other two records on the first page aren't included in the second page.
171
-
172
-
To achieve deterministic ordering, add orders on columns that contain unique values, or values that are semi-unique.
173
-
174
-
#### Deterministic example
175
-
176
-
This query is like the [nondeterministic one](#nondeterministic-example), but it includes the **Case ID** column that includes unique values. It's also ordered by **Status**, but also ordered using **Case ID**. The results look like this:
In the next page, the cookie will have `Case-0032` stored as the last record in the first page, so page two will start with the next record after that record. The results look like this:
Because this query orders unique column values, the order is consistent.
201
-
202
-
### Best practices for orders when paging data
203
-
204
-
> [!NOTE]
205
-
> When possible, queries should order on the primary key for the table because Dataverse is optimized for ordering on the primary key by default. Ordering by non-unique or complex fields cause excess overhead and slower queries.
206
-
207
-
When you retrieve a limited set of data to display in an application, or if you need to return more than 5,000 rows of data, you need to [page the results](page-results.md). The choices you make in determining the order of the results can determine whether the rows in each page of data you retrieve overlaps with other pages. Without proper ordering, the same record can appear in more than one page.
208
-
209
-
To prevent the same record from appearing in more than one page, apply the following best practices:
210
-
211
-
It's best to include a column that has a unique identifier. For example:
212
-
213
-
- Table primary key columns
214
-
- Autonumber columns
215
-
- User/contact IDs
216
-
217
-
If you can't include a column with a unique identifier, include multiple fields that will most likely result in unique combinations. For example:
218
-
219
-
- First name + last name + email address
220
-
- Full name + email address
221
-
- Email address + company name
222
-
223
-
224
-
#### Anti-patterns for orders when paging data
225
-
226
-
The following are ordering choices to avoid:
140
+
#### Override default choice columns sort order
227
141
228
-
- Orders that don't include unique identifiers
229
-
- Orders on calculated fields
230
-
- Orders that have single or multiple fields that aren't likely to provide uniqueness such as:
142
+
You can override the default sort order for choice columns by setting the [fetch element](reference/fetch.md)`useraworderby` (*Use Raw Order By*) boolean attribute. When this attribute is set, all sorting of choice columns will use the integer values instead.
231
143
232
-
- Status and state
233
-
- Choices or Yes/No
234
-
- Name values by themselves. For example `name`, `firstname`, `lastname`
235
-
- Text fields like titles, descriptions, and multi-line text
0 commit comments