vvdatasrc/getData: API Failure

[robert.swanson]

If mixed case inside the field is a possibility, and you don't want the users to worry about getting the case just right in their search value, there are two things you could try:

(1) Switch the data source's SQL sort sequence back to *LANGIDSHR (or if the portal default sort is *LANGIDSHR, you could set the data source to *DEFAULT). This will make your WHERE clause segment case-insensitive. It should perform much better this time since it's only checking one column (your filter column), whereas before with the global search you were making it check all the character columns.

(2) In the event (1) doesn't give you the performance you'd like, you could leave the data source in *HEX sort and add an explicitly upper-cased field to your data source. Add it to the SELECT clause as "UPPER(your_field_name) as your_field_name_UC", then you can use that _UC column for your filter (doesn't matter that the column is not shown in the grid). Be sure to set the filter to Force Uppercase so it's doing an apples-to-apples comparison to the column value.

[gwilburn]

I feel like we are going around in circles... the ONLY reason I was going to a different sort sequence was to get NAB to open the widget.

Performance within the app was NEVER an issue. The search performance is very acceptable.

#1 Above doesn't work because that is where I started - I can't open the grid widget in NAB with these settings.

I didn't try #2 - I'd rather see the NAB issue addressed. This data source is NOT the problem.

EDIT: I also have my grid setup to not autoload. Again, I don't understand how NAB is failing when it's not actually loading the data source

[robert.swanson]

I will reach out to you directly to have a look at this via Zoom. I thought the root issue was a timeout on the data source load, but perhaps there's a bit more to it than that.