"Find in Results Grid" feature like SSMSBoost had for SSMS

[gregclerk]

SSMBoost (now abandoned) had this feature for SSMS:
Find in Results Grid

Would it be possible to add this sort of feature to this SqlDataInspector extension?

Thanks!

[Tix2garr]

That would be pretty nice. :-)

[ernstc]

Thank you for this feature request. Actually the results are loaded only for the selected page, so if you mean searching data in the loaded page results it should not be a problem. But if you mean searching through all the results for the query, in all pages, this can be an heave task for those tables with thousands or millions or rows.

[gregclerk]

I was referring to the entire result set like SSMSBoost does (that add-in has actually been resurrected but is only for SSMS not Azure Data Studio).

Is this a VS Code issue where it only loads the current page? It's strange because SSMS performs much better with displaying/copying large result sets than Azure Data Studio.

Thanks

[ernstc]

It's not an issue of VS Code or Azure Data Studio. The Grid result that you see in the extension is part of the extension and has limited capabilities because it is a new Grid. It is not the same grid that you see when you execute the query in a normal Query page.

The grid in the extension loads only the selected page for performance reasons. You can change the size of the page up to 100 rows. Searching in the entire resulting dataset is just a performance concern for both Azure Data Studio and for the DB server in case of very huge datasets.

[Tix2garr]

Yes, but.... You are already kinda "searching" all the entire table for a specific column.

When you choose a column of a table, it lists all of the distinct values for that column, which is kinda searching.

Some thoughts/options:

• Cache the distinct values that have already been viewed and search those.
• Maybe only allow searches in columns that have been selected in the Columns window and already cached.
• Or maybe put up a warning that the user is attempting to search a column that hasn't been cached.
• Give the user the ability to define just how many rows there are per page, not limited to 100. Everyone has a different setup and therefore performance could be worse or way better. If the number they choose is over X records (500, 1000, 5000, something), maybe put up a warning about performance. But in general, allow the user to determine what will kill the performance. (Yes, you will probably want a max like 5,000 or something, based on what you have found to just lock stuff up. Or other testers.)

I strayed a bit but in general, leave it up to the user to basically decide how much to pull in, with some hard there-is-no-way-your-computer-could-handle-more-than-this limits. :-)

Again, love this extension!! :-)