Why xWebDataGridRowLimit was introduced

Prior to Service Package 33 (Summer, 2024), the system option DataGridRowLimit was used to control the maximum number of rows returned in:

• iWeb child form grids and
• xWeb API query responses (e.g., GetQuery, GetQueryView).

This shared configuration often caused complications because adjustments made to optimize one interface (e.g., reducing load times in iWeb) could negatively impact the other (e.g., returning incomplete datasets via xWeb). As organizations began to rely more heavily on xWeb for integrations, a clear need emerged to decouple iWeb and xWeb from this shared-configuration behavior.

To address this, netFORUM introduced a new system option in SP33: xWebDataGridRowLimit

xWebDataGridRowLimit: A dedicated paging control for xWeb

The xWebDataGridRowLimit system option was added to allow independent control over xWeb query paging, without altering how data is displayed within iWeb.

This enhancement enables administrators and developers to fine-tune API performance for third-party integrations and custom applications, without compromising staff-facing workflows in iWeb.

• To access the xWebDataGridRowLimit system option, navigate to Admin > System Options > System Options > xWeb.

Differences in the system options

The "values" in the third column refer to the number of rows.

Notes

If a value for xWebDataGridRowLimit:

• is specified, it supersedes the DataGridRowLimit value, and is used for xWeb query calls.
• is not specified, xWeb query calls use the DataGridRowLimit value.

netFORUM recommendations

netFORUM recommends recommends the following configuration approach.

1 - Use xWebDataGridRowLimit for all xWeb integrations

If you're using xWeb to deliver results to an external system, you should explicitly define xWebDataGridRowLimit to optimize the paging experience.

netFORUM recommendations:

• A value of 100 – 300 rows per request depending on the complexity and size of your dataset.
• Test with your specific queries to balance performance and payload size.
• From the Higher Logic side, in some cases, a value in the 500 – 1000 rows may be appropriate. We'll work with you to make this adjustment. The first step is always to check what was working previously with DataGridRowLimit.

2 - Leave DataGridRowLimit focused on iWeb

Keep DataGridRowLimit set to a value that supports a responsive experience for internal users, typically no more than 300 rows. You do not have to adjust this just to fix xWeb performance.

Updated troubleshooting guidance

Previous behavior: If xWeb was returning truncated results, admins often guessed an appropriate value to raise DataGridRowLimit.

The recommended new approach is:

1. Check the current value of DataGridRowLimit

• If results were previously returning correctly when using this value, it's a good starting point.

2. Set the value of xWebDataGridRowLimit to match the value of DataGridRowLimit

• This ensures continuity with the previous behavior and enables future flexibility.

3. Fine-tune the value of xWebDataGridRowLimit only if needed

• If xWeb results are still too large or too slow, independently adjust the value of xWebDataGridRowLimit based on actual usage.

TIP: Use the same value for xWebDataGridRowLimit that was working for DataGridRowLimit, rather than guessing. This ensures consistent and predictable behavior.

Summary

• The xWebDataGridRowLimit system option was created in order to separate xWeb paging from iWeb. This allows for more control and better performance tuning.
• Always start troubleshooting by reviewing DataGridRowLimit because it reflects the original working configuration.
• Set xWebDataGridRowLimit explicitly to optimize API performance without impacting the iWeb user experience.