Posts

O Database Snaphot (ou “instantâneo de Banco de Dados”, se você estiver no SQL Server em português – Que nome terrível, hehehe) é um banco de dados _somente leitura, _onde o SQL Server guarda os dados originais de tudo o que está sendo alterado pelos usuários, para que seja possível realizar verificações (dentre outras coisas) de como estava o banco antes destas ocorrerem. Ao contrário do que muita gente pensa, as alterações ocorrem nas páginas de dados e não no objeto que está sofrendo alteração. O SQL Server utiliza um recurso chamado “Copy-on-write” onde, antes da página ser alterada, os dados originais são armazenados no snapshot. ...

Após a migração do Team Foudation Server 2010 de servidor, fui realizar a configuração dos backups através do TFS Powertools (disponibilizado pela Microsoft no link: http://visualstudiogallery.msdn.microsoft.com/c255a1e4-04ba-4f68-8f4e-cd473d6b971f) e me deparei com o seguinte erro: ...

No dia 07/12, foi realizado na PUC o SQL Server Internal Ops, um evento idealizado pelas comunidades SQL Server RS e MSITPSC, com o apoio da Microsoft e da Dell. Há muito tempo que eu ansiava por um evento do gênero aqui em Porto Alegre, com foco 100% em SQL Server, uma vez que já houveram eventos semelhantes em São Paulo, Rio de Janeiro (Que eu felizmente consegui ir), Recife (com o SQL Saturday) enquanto nós, que moramos aqui no RS, não tínhamos nada. ...

Onde trabalhamos, utilizamos o Source Safe para realizar o controle de alterações nas functions e procedures de Banco de Dados. Foi criado um projeto que contém os objetos e, dentro do SSMS, fazemos o checkout / checkin deles, já integrado com o Source Safe. Acontece que hoje, ao tentar migrar o projeto para abrirmos no SQL Server Management Studio 2012, apareceu o erro: Error: No such interface supported File: vsee\internal\inc\vscomptr.inl Line number: 259 ...

6 meses depois do último post (e com o planejamento de ano novo completamente furado – o de postar pelo menos 1 vez a cada 15 dias… 🙁 )… Dica rápida para quem usar EXISTS : Nunca utilize uma função de agregação quando utilizar o EXISTS. Por quê? Segue um script rápido que insere alguns poucos registros em uma tabela para testarmos… CREATE DATABASE TesteExists --Super original, não? :-) GO USE TesteExists GO CREATE TABLE Pessoa (Nome varchar(20), Nascimento datetime, Sexo char(1), CPF varchar(11), EstadoCivil char(1)) GO INSERT INTO Pessoa Values ('Logan', '19810101', 'M', '11111111111','C') INSERT INTO Pessoa Values ('Denise','19800101', 'F', '22222222222','C') INSERT INTO Pessoa Values ('Sophia', '20120101', 'F', NULL,'S') GO IF EXISTS (SELECT MAX(Nascimento) FROM Pessoa WHERE nome = 'xxxxx') SELECT 'OK' ELSE SELECT 'NOK' ...

Muitas vezes precisamos que uma determinada coluna receba um valor padrão, por exemplo, uma tabela de pedidos que, ao inserir um registro novo, coloca por padrão a data atual no campo que referencia a data do pedido. Ok, mas como é que eu faço isso? Muito simples, pequeno gafanhoto, ao criar uma tabela: CREATE TABLE MinhaTabela ( Codigo int identity, Nome varchar(100) NOT NULL, Valor int NOT NULL, Data datetime not null CONSTRAINT DF_MinhaTabela_Data default getdate() ) Putz! Mas o campo Valor também tinha que ter um valor Default… Será que eu consigo colocar sem ter que refazer a criação ou dropar a coluna? ...

As CTE’s são muito semelhantes às tabelas derivadas, mas com uma boa vantagem… De acordo com o BOL a estrutura para uma CTE é: WITH expression_name [ ( column_name [,...n] ) ] AS ( CTE_query_definition ) SELECT FROM expression_name; Uma comparação de uso entre uma tabela derivada e uma CTE: Tabela derivada: SELECT * FROM (SELECT Nome, Cidade FROM CLIENTES WHERE DataCadastro > '2011-01-01') AS CLI2011 Usando CTE: ;WITH CLI2011 AS ( SELECT Nome, Cidade FROM CLIENTES WHERE DataCadastro > '2011-01-01') SELECT * FROM CLI2011; Note o ‘;’ antes do WITH… Ele está lá por eu considerar uma boa prática, uma vez que sempre que você utilizar uma CTE, caso tenha alguma outra consulta antes, ela obrigatoriamente deve terminar com o ‘;’. Então, por via das dúvidas, sempre coloque ele antes do WITH, quando for usar uma CTE. ...

Passei os últimos dias migrando de servidores e um dos meus objetivos era pegar o nosso portal, que hoje está em um Ubuntu e passar para o novo server, Windows. Após fazer as configurações do php, mysql, iis, etc, notei que as páginas estavam sendo abertas com a acentuação totalmente errada, mesmo as informações no MySQL estando corretas. Fucei em tudo o que era lugar. Converti a codificação dos arquivos .php para UTF-8, para ANSI, para ISO-8859-1, mas nada adiantou. ...

Post rápido… Estava cansado e ir no design do SSMS pra ver a descrição de algumas colunas e resolvi pegar as tabelas relacionadas e montar um script que fizesse isso. Segue: SELECT OBJECT_NAME(c.object_id) Tabela, c.name Coluna, ex.value Descricao FROM sys.columns c LEFT OUTER JOIN sys.extended_properties ex ON ex.major_id = c.object_id AND ex.minor_id = c.column_id WHERE OBJECT_NAME(c.object_id) = ‘Sua_Tabela’ ORDER BY OBJECT_NAME(c.object_id), c.column_id Espero que ajude… 🙂 []’s

Existem 4 funções de ranqueamento que podem ser utilizados com a cláusula OVER: ROW_NUMBER RANK DENSE_RANK NTILE Um exemplo de uso: SELECT orderid, custid, val, ROW_NUMBER() OVER(ORDER BY val) AS rownum, RANK() OVER(ORDER BY val) AS rank, DENSE_RANK() OVER(ORDER BY val) AS dense_rank, NTILE(10) OVER(ORDER BY val) AS ntile FROM Sales.OrderValues ORDER BY val; O retorno é: orderid custid val rownum rank dense_rank ntile ----------- ----------- --------- ------- ------- ---------- ----- 10782 12 12.50 1 1 1 1 10807 27 18.40 2 2 2 1 10586 66 23.80 3 3 3 1 10767 76 28.00 4 4 4 1 10898 54 30.00 5 5 5 1 10900 88 33.75 6 6 6 1 10883 48 36.00 7 7 7 1 11051 41 36.00 8 7 7 1 10815 71 40.00 9 9 8 1 10674 38 45.00 10 10 9 1 ... 10691 63 10164.80 821 821 786 10 10540 63 10191.70 822 822 787 10 10479 65 10495.60 823 823 788 10 10897 37 10835.24 824 824 789 10 10817 39 10952.85 825 825 790 10 10417 73 11188.40 826 826 791 10 10889 65 11380.00 827 827 792 10 11030 71 12615.05 828 828 793 10 10981 34 15810.00 829 829 794 10 10865 63 16387.50 830 830 795 10 (830 row(s) affected) A função ROW_NUMBER() retorna uma ordenação sequencial para o resultado da consulta, baseado no que foi especificado no ORDER BY da cláusula OVER. Note que eu poderia retornar a ordenação pela coluna custid, modificando apenas a coluna rownum e mantendo a mesma ordem no retorno da consulta. ...