While executing the WAITFOR statement, the transaction is running and no other requests can run under the same transaction.
The actual time delay may vary from the time specified in time_to_pass, time_to_execute, or timeout and depends on the activity level of the server. The time counter starts when the thread associated with the WAITFOR statement is scheduled. If the server is busy, the thread may not be immediately scheduled; therefore, the time delay may be longer than the specified time.
WAITFOR does not change the semantics of a query. If a query cannot return any rows, WAITFOR will wait forever or until TIMEOUT is reached, if specified.
Cursors cannot be opened on WAITFOR statements.
Views cannot be defined on WAITFOR statements.
When the query exceeds the query wait option, the WAITFOR statement argument can complete without running. For more information about the configuration option, see query wait Option. To see the active and waiting processes, use sp_who.
Each WAITFOR statement has a thread associated with it. If many WAITFOR statements are specified on the same server, many threads can be tied up waiting for these statements to run. SQL Server monitors the number of threads associated with WAITFOR statements, and randomly selects some of these threads to exit if the server starts to experience thread starvation.
You can create a deadlock by running a query with WAITFOR within a transaction that also holds locks preventing changes to the rowset that the WAITFOR statement is trying to access. SQL Server identifies these scenarios and returns an empty result set if the chance of such a deadlock exists.