[Feature Request]: bring Select Top 1000 back to the top level menu

[gregveres]

Feature Description

I just updated to 1.37.0 and was very shocked to see that Select Top 1000 has moved to a submenu. I would bet that if you put counters in your code, you would find that this is the most selected option, why did you hide it? I had to hunt around for it to find where it had gone.

Please consider bringing it back to the top level, or have New Query populate with the standard Select Top 1000 query. If you go this route, you could even pre-select all of the query so that it someone didn't want the top 1000, they could just start typing their new query and the top 1000 query text would vanish, but if you did want to the top 1000 text, it would be there.

Problem and Motivation

This is a big back step in usability. It now takes longer to get to the most likely menu choice you are going to use.
Maybe this Select Top 1000 option was buried because you expect people to use the Edit Data window instead? That isn't the case because the Edit Data window is currently useless because you can't modify the script that selects the data - see the comment on that thread.

Related Area

• Connection dialog (SQL Server | Azure browse/Fabric browse)
• Query editor
• Query results panel
• Object Explorer
• GitHub Copilot integration
• Preview/Edit data
• Table Designer
• Schema Designer
• Schema Compare
• Local SQL Server Container provisioning
• SQL database in Fabric provisioning
• DACPAC/BACPAC export/import
• SQL Database projects
• Query Plan Visualizer
• Other (please describe below)

If you selected "Other", please describe the area

No response

Confirmation

• I have searched existing feature requests and couldn't find a match
• I want to help implement this feature

[kburtram]

@croblesm I recall we discussed this specifically about pulling SELECT TOP 1000 from the other scripting commands. If I recall correctly, the thinking was that View/Edit Data would replace SELECT TOP 1000 for the common "just peek at the data" use case, while SELECT TOP 1000 would remain available for users who specifically want to generate starter SQL for customization, access execution plans, export data, etc.

The rationale generally makes sense to me, but @gregveres raises a valid point about the workflow impact. Could you please take a look at this feedback?

[gregveres]

@kburtram @croblesm
I personally don't see Edit Data as a viable replacement for Select Top 1000 because I never want to see the top 1000 without a where clause or some joins. But i also don't want to have to build the boiler plate portion of the query every time I want to run a query. Select Top 1000, coupled with "mssql.query.preventAutoExecuteScript": true provides me with the boiler plate starting point.

My arguments for asking for preventAutoExecuteScript, was the same as this request. 99% of the time, my request has some sort of where or join clause. So, I don't want the system to go fetch 1000 rows from my table, just so I can throw it away. Since Edit Data doesn't honour preventAutoExecuteScript, that's what would be happening if I switched over to using Edit Data all the time.

Now, if you changed Edit Data to expose the underlying script and had it honour preventAutoExecuteScript and it show the script when initially brought up if preventAutoExecuteScript was true, then I would see how it could be a replacement for Select Top 1000.

[aasimkhan30]

@gregveres While we investigate the context-menu positioning issue, could you try assigning a keyboard shortcut for this command in the meantime?
Once the shortcut is set, just select a table in OE and pressing the shortcut should work.

[gregveres]

Ok, I will try that out.

[sturginho]

Why does "Sql Scripts" need its own submenu? There's only 3 options, they could all easily fit at the top level

[kburtram]

@croblesm any thoughts on this one?