How to Execute SQL Query without Displaying results

I'm surprised nobody came up with the answer : switch on the "discard query results after execution" option; l I'm pretty sure that was what the interviewer was after. SET FMT ONLY is totally different thing IMHO.

In SSMS

• open a new query
• in the menu select Query / Query options
• select the Results pane
• check the "discard result after execution"

The reason you might want to do this is to avoid having to wait and waste resources for the results to be loaded into the grid but still be able to have e.g. the Actual Execution Plan.

Sounds like a dubious interview question to me. I've done it, I've needed to do it, but you'd only need to do so under pretty obscure circumstances. Obscure, but sometimes very important.

As @gbn says, one programmatic way is with SET FMTONLY (thanks, now I don't have to dig it out of my old script files). Some programs and utilities do this when querying SQL; first they submit a query with FMTONLY ON, to determine the layout of the resulting table structure, then when they've prepared that they run it gain with FMTONLY OFF, to get the actual data. (I found this out when the procedure called a second procedure, the second procedure returned the data set, and for obscure reasons the whole house of cards fell down.)

This can also be done in SSMS. For all querying windows, under Tools/Options, Query Results/SQL Server/Results to XX, check "Discard results after query executes"; for only the current window, under Query/Query Options, Results/XX, same checkbox. The advantage here is that the query will run on the database server, but the data results will not be returned. This can be invaluable if you're checking the query plan but don't want to receive the resulting 10GB of of data (across the network onto your laptop), or if you're doing some seriously looped testing, as SSMS can only accept so many result sets from a given "run" before stopping the query with a "too many result sets" message. [Hmm, double-check me on that "query plan only" bit--I think it does this, but it's been a long time.]

insert anothertable
Select * from Table_Name

Executes the select but returns nothing

set noexec on 
Select * from Table_Name

Parses but does not execute and so returns nothing.

Perhaps the interviewer intended to ask a different question:

How would you execute a SQL query without returning the number of results?

In that case the answer would be SET NOCOUNT ON.

If you need the query to execute but don't need the actual resultset, you can wrap the query in an EXISTS (or NOT EXISTS) statement: IF EXISTS(SELECT * FROM TABLE_NAME...). Or alternately, you could select INTO #temp, then later drop the temp table.

In my case I was testing that the data was behaving in all views, e.g. any cast() functions weren't causing conversion errors, etc. so supressing the actual data wasn't an option, displaying wasn't too bad but a bit of wasted resource and better not to diplsay if sending results only in text.

I came up with the following script to test all the views in this way, the only problem is when it encounters views that have text/ntext columns.

declare csr cursor local for select name from sys.views order by name
declare @viewname sysname
declare @sql nvarchar(max)

open csr
fetch next from csr into @viewname
while @@fetch_status = 0 begin
    --set @sql = 'select top 1 * from ' + @viewname 

    set @sql = 'declare @test nvarchar(max) select @test = checksum(*) from ' + @viewname 

    print @viewname

    exec sp_executesql @sql
    fetch next from csr into @viewname
end
close csr
deallocate csr

Is the goal to suppress all rows? Then use a filter that evaluates to false for every row:

SELECT * FROM Table_Name WHERE 1 = 2

If you are using PostgreSQL you can put your select in a function and use PERFORM The PERFORM statements execute a parameter and forgot result.

A PERFORM statement sets FOUND true if it produces (and discards) one or more rows, false if no row is produced.

https://www.postgresql.org/docs/9.1/plpgsql-statements.html#:~:text=A%20PERFORM%20statement%20sets%20FOUND,if%20no%20row%20is%20returned.

Yet another use case is when you just want to read all the rows of the table, for example testing against corruptions. In this case you don't need the data itself, only the fact that it is readable or not. However, the option name "Discard results AFTER execution" is a bit confusing - it tells me that the result is fetched and only then discarded. In contrary, it fetches the data for sure but does not store it anywhere (by default the rows are put into the grid, or whatever output you have chosen) - the received rows are discarded on the fly (and not AFTER execution).

Simple way is to,

Select * into #temp from Table_Name