SET ROWCOUNT VS TOP in SQL Server

SET ROWCOUNT statement is marked as Deprecated!!

Both SET ROWCOUNT statement and TOP clause are used to limit the number of rows returned. However there are some significant differences between them. They are listed out here.

SET ROWCOUNT statement	TOP clause
It is specific to a batch. It will affect all DML operations until it is reset to 0	It has statement level scope and it will not affect other statements until specifiedeach for them
Variable can be used in all version. Ex SET ROWCOUNT @var	Variable can be used only from version 2005 onwards like TOP (@var)
Not possible to set percentage	Possible to set percentage option. Ex SELECT TOP 20 PERCENT * FROM TABLE
Not possible to specify decimal value	Possible to specify decimal values along with PERCENT option.
It is executed outside of actual DML and its value is not part of query plan	The expression used in TOP clause will be considered as part of query plan.
Multiple SET ROWCOUNT statements are allowed in a single batch. However the lastly available before the statements will be used. SET ROWCOUNT 10 SET ROWCOUNT 100 SELECT * FROM SYS.OBJECTS SET ROWCOUNT 0 The COUNT  100 will be considered for execution	Multiple TOP is not allowed however they can be nested. SELECT TOP 10 * FROM ( SELECT TOP 100 * FROM SYS.OBJECTS ) AS T The final result will have maximum of 10 rows
As this is executed as a seperate statement. It can not be part of VIEW definition	It can be part of VIEW definition.
This is marked as Deprecated. Avoid using this	Always available in all versions

Trovato qui.

Pinal Dave dice che è una porcheria:

SET ROWCOUNT option is ignored for INSERT, UPDATE, and DELETE statements

Setting the SET ROWCOUNT option causes most Transact-SQL statements to stop processing when they have been affected by the specified number of rows. This includes triggers

Killare un processo in “arresto in corso” sui sistemi Windows

Mi è capitato oggi di dover litigare con un processo su un server Windows 2008 che, dopo essere stato ritenuto (giustamente) colpevole del blocco della Console “Symantec Endpoint Protection”, ha deciso di freezarsi in quel fastidioso stato che solitamente ci impone un bel riavvio del server.

Essendo tuttavia il server in produzione e non recando il processo bloccato nessun disservizio all’utenza, ho ritenuto eccessivo un reboot a metà mattina.

In sostanza, un metodo per forzare l’arresto di un servizio bloccato in “arresto in corso” o “stop pending” è il seguente:

Anzitutto è necessario il PID del processo da killare, lo possiamo trovare agilmente tramite la console “services.msc”, aprendo le proprietà del servizio bloccato, ne ho aperto uno a caso evidenziando il nome processo univocamente assegnato dal sistema:



Aprire quindi un prompt dei comandi (mi raccomando di usare un account con privilegi di amministrazione), e digitare la seguente riga:

sc queryex "[nomeservizio]"

Appariranno tutta una serie di informazioni carine, tra cui STATO (che sarà “ARRESTO IN CORSO” o “STOP PENDING”) e PID.

Ora digitiamo:

taskkill /F /PID [pid_servizio]

E come per magia il servizio si stopperà.
Per esperienza personale ho riavviato il servizio stesso dopo pochi istanti senza rilevare problema alcuno, e risolvendo anzi il problema iniziale.

Nota importante: verificate che tutti i servizi dipendenti dal servizio in questione siano ancora avviati perchè un kill brutale del servizio padre potrebbe portare alla morte dei servizi figli, senza che il sistema avverta in alcun modo l’utente.

Un sentito ringraziamento per la dritta al collega Cillo.

---

Testato su Windows Server 2003.
Trovato qiu.