Eu uso muitas vezes ROWCOUNT, normalmente para partir certas operações em batches. Exemplo clássico, um delete gigante que não queremos que encha o nosso transaction log. E sim, é mais usual do que pensamos. A questão deste post é que temos de ter muito cuidado como usamos esse rowcount, porque alguém pode mexer no nosso código mais tarde. A sério, não percebo porque é que alguém algum...
Surgiu num cliente uma questão bem pertinente mas a que já vamos estando habituados. Será que vale a pena fazer upgrade de SQL Server 2014 Standard para SQL Server 2017 Standard? tl;dr Sim. Este cliente tem um misto de SGBD’s num misto de versões.A questão surgiu para um certo servidor que, estando agora em SQL Server 2014, poderia ser actualizado para SQL Server 2017. Duas vantagens que...
Se bem se lembram, há uns dias fiz aqui um post a relembrar termos cuidado quando fazemos um select into para uma temporária. Este é outro caso em que as coisas podem não acabar como esperámos. Da última vez mostrei como num select into o coluna fica nullable se a tabela fonte tem a coluna nullable. Nesta demo mostro o contrário, como partimos de uma coluna que...
Passa muitas vezes despercebido aos mais incautos. Mesmo que tenhamos uma query em que explicitamente colocamos uma coluna not null, o select into vai deixar a definição da coluna nullable. Mas porque é que isso interessa? Interessa porque sabemos que é muito mais do que um preciosismo definirmos o nosso modelo de dados como deve de ser. Há muitas maneiras de o SQL Server melhorar um plano...
Eu sei que posso já ser considerado da “velha guarda”. Aprendi a programar com 11 anos, há mais anos do que muitos colegas meus têm de vida. Se calhar é por isso gosto de ver coisas feitas à moda antiga. Uma delas é ver todos os declare no topo do script. E de repente: Mas assim apenas declaro mais abaixo e só aí vou usar o espaço...
Há erros que nunca cometemos. Por exemplo, um overflow num int que nos faz pensar por que raio é que a coluna não foi logo definida como bigint. Ou um destes casos que quero mostrar agora. Porque nunca acontecem. Sabemos que se tentarmos ultrapassar certos limites, o SQL Server nos avisa. Ou este Mas há outros… Vamos correr de novo para vermos os tamanhos reais em bytes...
Conversa interessante com um colega de profissão, estamos a discutir um caso em que anda um bug à solta e de repente digo-lhe: “Mas nem sempre um TRY/CATCH funciona como estás à espera, por vezes há erro dentro do código no TRY e não salta para o CATCH”. Sim, há quem não acredite. Mas acontece. E até está bem documentado. Vamos ver um desses casos para dissiparmos...
Há poucos dias fiz um post sobre como nem sempre um índice ajuda em updates e deletes. Para situar quem não o leu, mostrei que um índice que à primeira vista pode ajudar nem sempre o faz. Por vezes até se revela desastroso em termos de performance. Mas como há sempre quem diga que “não cobriste todos os casos, se tivesses __________ seria diferente”. E ainda bem...
O meu post de há algum tempo sobre o tamanho das variáveis e o memory grant deu algo que falar, por isso resolvi, ao estilo de Hollywood destes últimos anos, revisitá-lo. Se se lembram desse post (também não foi há assim tanto tempo…) a questão era: O tamanho das variaveis não interessa, se eu colocar um varchar(max) ou varchar(50) é igual porque o SQL Server só usa...
E se, de repente, ouvirem uma coisa destas? A quantidade de colunas não importa num select, não estou a agregar nem ordenar a saída. Pois, e eu já acreditei no Pai Natal, mas já foi há algum tempo. Vamos criar umas tabelas para testar esta ideia? Podemos agora correr este pedacinho de código? Nada de estranho se passa, como esperado. Mas no fundo o que queríamos era...