SQL Server Performance & Troubleshooting – Where Milliseconds Matter 🚀

Hi Guys, Today, after the last tips  SQL Server, Concatenates text from multiple rows into a single string! I want to show you another tips! I suggest you bookmark this page. This way, when you need it, a copy and paste will suffice! How many times did it take you to have a table with a fixed number of rows at your fingertips? Here it is!   Generate a number of rows Suppose you want to generate 10 rows. Just write (or copy and paste) this command: ; WITH progr(x) AS ( SELECT 1 UNION ALL SELECT x+1 FROM progr WHERE x < 10 ) SELECT x FROM progr OPTION (MAXRECURSION 0); And here is the result: What we have done? simple: we used a CTE in order to trigger recursion. That's all for today! Stay tuned mate! Luca Luca Biondi @ SQLServerPerformance blog! Next post: Previous post: SQL Server 2019 and the Approx_Count_Distinct function

Hi  guys,  Today we take a little break, just a little post for a useful super tip!   Today a colleague of mine had developed a function that used a CTE to do what today I will show you can be done with a single line of SQL code. Needless to say, everything was extremely slow.   Enjoy the reading of this supertip! Concatenates text from multiple rows into a single string Suppose you have an order or an invoice with a variable number of rows. Think of the Ordtes and OrdRig tables that we have used in so many examples in this blog. We extract the data of an order with this command: SELECT id, idordtes, Descr FROM ordrig WHERE IdOrdtes = 33 ...the data:       Suppose we need to have all descriptions on the same row. How to do it without cursor ore CTE? Simple!  DECLARE @Names VARCHAR(8000) SELECT @Names = ISNULL(@Names,'') + ' ' + Descr FROM ordrig WHERE IDordtes = 33 SELECT @Names   Trying this you will get: et vo...

Carissimi lettori, Oggi un articolo veloce veloce! Vi faccio vedere un piccolo tips che risulta essere molto comodo in tante situazioni. Quante volte avete avuto bisogno di sapere da quali colonne è composto una tabella , quante volte poi un attimo dopo aver avuto bisogno di sapere quali colonne accettano il null o meno oppure se è presente un default. Certo queste sono tutte informazioni facili da reperire ma occorre tutte le volte navigare tra i menù dell' SMSS. C'è però una modo molto più comodo e rapido . Buona lettura! La stored procedure sp_help SQL server possiede un certo numero di stored procedure a volte davvero comode. E' il caso della stored procedure sp_help. Dal management studio eseguite il comando sp_help seguito dal nome di una tabella tra apici. Ad esempio: sp_help 'Customer' Eseguitela e guardate quello che ritorna: Come vi dicevo con un solo comando abbiamo estratto un del po di informazioni. Tra l...

Carissimi lettori,  E' appena iniziato Novembre noi però siamo nuovamente assieme per parlare di ottimizzazioni! Un paio di articoli fa parlavamo di quanto fosse utile indicare lo schema davanti al nome della tabella al fine di migliorare le prestazioni delle nostre Query (qui SQL Server Ottimizzazioni: non omettere il nome dello schema! (schema name resolution) ) Oggi invece parliamo di un altra ottimizzazione anch'essa facilmente implementabile. Parliamo infatti dell'utilizzo dell' asterisco (*) nelle SELECT. Mi raccomando, seguitemi numerosi! Buona lettura! Chi è senza peccato scagli la prima pietra Lo ammetto! Capita anche a me, scrivendo Query per delle interrogazioni esterporanee, di iniziare con il classico: SELECT * FROM TABELLA JOIN .... etc etc etc. Certo l'utilizzo dell'asterisco è comodo: in un colpo solo estraggo tutti le colonne della tabella . Se però la nostra query viene utilizzata ad un applicativo, magar...

Carissimi lettori! Oggi, torniamo a parlare di ottimizzazione ! Già perché un sistema veloce è anche sinonimo di sistema di qualità! Comprereste da Amazon se per aggiungere un articolo nel carrello impiegereste due o tre minuti? Non credo! Si parte! Con questo articolo vorrei sottolineare questo aspetto non tanto conosciuto: quando scriviamo le nostre Query (a proposito da pronunciarsi “Quiri”) è meglio specificare sempre lo Schema (pronunciato “Schima”) In pratica: SELECT * FROM DBO.TABELLA Anziché: SELECT * FROM TABELLA Questo per due motivi: Primo motivo Se non specifichiamo lo schema sarà SQL Server a doverlo fare.  Dovrà fare un paio di verifiche veloci che sono: Determinare lo schema di default e verificare se esiste una tabella con quel nome nello schema di default Se non esiste nessuna tabella allora dovrà anche verificare se una tabella con quel nome è presente nello schema dbo. Normalmente sono operazioni svolte mo...

Carissimi lettori, ben torrnati! L'articolo di ieri è stato sicuramente intenso ( Database corrotti, recupero tramite DBCC WRITEPAGES ) per cui oggi sarò molto più breve. Promesso! Vi farò vedere come eseguire una ricerca case sentitive anche se la collate impostata sul database non lo è. Ricerche case sensitive Supponiamo di aver impostato sul nostro database una collate che non è case sensitive. Ovvero non è sensibile alle maiuscole e minuscole. Supponiamo ora di avere una tabella "elenco" dentro la quale sono memorizzati una serie di nomi, come questa sotto: Ora, il nostro database non è case sensitive per cui una interrogazione come questa: SELECT * FROM ELENCO WHERE CODICE = 'LUCA' ritornerà sempre entrambi i record. Ma se volessimo restituito solamente il codice dove LUCA è scritto solo in minuscolo? Come fare? Bhe, il trucco è semplice. Avete presente quando abbiamo parlato nei giorni scorsi di COLLATE ?  (fai click qui: Error...