O Visual Studio 2008 vem com o SQL Server 2005 Express (9). Essa versão é legal, é bem melhor que a versão de 2000 (8). Só que a versão 2008 (10) é melhor ainda. Uma das que eu mais gosto é o Intelisense no SQL Management Studio, e tem ainda um monte de outras features legais, que você pode ler no blog do Leandro Daniel.

Não sei porque a Microsoft não liberou ainda uma versão do Visual Studio 2008 empacotado já com o SQL Server 2008, e tudo com os últimos service packs. Instalei meu Windows 7, e tive que instalar o VS, instalar o SP do VS, e instalar o SP do SQL. Cansa. Cansa mais ainda porque eu não queria o SQL Server 2005. Busquei de toda forma atualizar o SQL Server 2005 para o 2008, mas não deu. Deve até ter um caminho, mas não encontrei. Melhor que perder mais 3 dias procurando é resolver de uma vez. Desinstalei o SQL Server 2005, instalei o 2008 Express, que já vem com Full Text Search e Reporting Services, algo que o 2005 também não tinha. O SQL Server Management Studio também já vem. Cool. E depois, de novo, instalei o SP1… porque não tem uma versão completa já com o SP1, só a versão básica, sem SSMS, sem RS, sem nada do que eu queria.

Essa odisséia de instalações me lembrou de algo: tenho clientes que não têm o SQL Server Express, trabalharam com a edição developer. Esta edição não usa named instances para se comunicar com o servidor, geralmente usa a instância padrão, que é só o nome da máquina, o que no meu caso era "BASSINOTE", já que minha máquina tinha esse nome. Na Windows 7 RC que estava instalado, eu tinha um SQL Server 2005 Express, e um SQL Server 2008 Developer, tinha 2 instâncias:

1. A padrão, do SQL Server 2008 Developer, que eu acessava somente pelo nome da máquina: "BASSINOTE"
2. A nomeada, do SQL Server 2005 Express, que eu acessava pelo nome da instância, que é padrão "SQLEXPRESS", ficando assim: "BASSINOTE\SQLEXPRESS".

Eu não podia não ter uma instância nomeada SQLEXPRESS, porque todo o ambiente de desenvolvimento assume que você tem essa instância. A string de conexão padrão para conexão de bases anexadas usa esta instância. Eu até podia mecher no machine.config, mas não ia resolver, ia ter que alterar outros lugares, e ficar atento com toda instalação. Melhor não.

Mas eu não queria instalar outra versão do SQL Server só para ter uma outra instância que respondesse no nome da instância padrão.

Atenção: Não sou especialista em SQL Server, vou descrever aqui apenas algo que fiz e funcionou para mim, então estou contando pra vocês. Não sei se essa é a melhor maneira de fazer ou se estou abrindo o cubo do Hellraiser ao alterar estas configurações. Sou MVP de C#, não de SQL Server… Se alguém tiver uma sugestão melhor, comente!

Aí entra o Sql Server Configuration Manager. Essa ferramenta, que roda via MMC, nos permite configura o SQL Server. Estava ajustando uns protocolos por lá, e percebi um item "Aliases" no treeview.

No meu caso há duas, porque estou rodando um SO de 64 bits, e ele separa as configurações dos clientes. Cliquei lá com o botão direito, e há uma opção "New Alias…":

Hmm… isso está ficando interessante. Apareceu essa tela:

Preenchi tudo. Escolhi "BASSINOTE" como nome do alias, e o protocolo named pipes, que é um protocolo "intra máquina" (para deixar no básico), e coloque como nome do server o próprio nome da máquina:

Você ainda pode escolher TCP e VIA como protocolos:

Fiz isso para os outros possíveis nomes, os nomes mais comuns, que são o ponto ".", o "(local)". Fui testar, e funcionou:

As quatro conexões são feitas à mesma instância do mesmo servidor.

Agora posso usar a instância nomeada como se fosse a padrão, o que não vai causar problemas quando eu estiver utilizando o código que está no repositório de um cliente que usa estas configurações. Muito bom!

Essa foi engraçada, para não dizer estranha. Ao tentar instalar o SQL Server 2008 na minha máquina ele disse que precisava instalar o .Net Framework. Eu pensei: “Aham, na minha máquina?”, como se minha máquina já não tivesse todas as versões do .Net Framework existentes. Pois é, não tinha. Ele pede o SP 1 do .Net Framework 3.5, que, até onde eu sei, ainda é beta. Como o SQL Server 2008 é RTM, pensei “Liberaram o SP1”. Engano meu. Mas que ele instalou, instalou. Sei lá que versão é a que está na minha máquina, mas é certo que agora eu tenho na máquina uma versão do SP1. Só não sei se é a final.

Se não for a RTM do SP1, se for o beta, o que vai acontecer com quem lançar o SQL Server 2008 em servidor de produção? Vai jogar bits beta em produção? Ruim, muito ruim. Espero estar enganado.

Estou instalando o recém lançado SQL Server 2008, mas tudo indica que ele vem com alguns probleminhas na instalação.

Se você usa Windows Vista instalado originalmente não em inglês, pode ter problemas na instalação. Na hora de rodas o check de instalação recebe um erro:

Pois bem, pesquisei em alguns lugares e percebi que o problema rola faz tempo, mas mesmo assim não foi resolvido ainda. Segui o recomendado no fórum, mas não resolveu o problema. A idéia seria pegar o ID da lingua de instalação do seu windows, e adicionar ela no registro.

Para pegar esse ID, seria só rodar:

string.Format("{0,3}", CultureInfo.InstalledUICulture.Parent.LCID.ToString("X")).Replace(" ", "0"); 

Para mim retorna 016.

E adicionar ao registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib

Ficaria assim:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\016

Copiando os valores “Counter” e “Help” de alguma outra chave, tipo a 009, para essa nova chave.

Pois bem, fiz isso, não rolou. Estou postando aqui o que fiz para resolver, porque vocês podem ter o mesmo problema.

Por causa da dica no Microsoft Connect colocada por um chinês, fiz um trace do problema à dll Microsoft.SqlServer.Configuration.SetupExtension.dll. O método CheckPerfMonCounter da classe FacetPerfMonCheck, faz uma rotina um pouco diferente da esplicada nos fóruns. Copiei e rodei. Resultado: 0416. Eu já tinha essa chave no meu registro, foi só acrescentar e copiar os valores “Counter” e “Help”:

E funcionou. Sem grandes stress. Mas teve que investigar…

A função para saber o id da sua lingua é a seguinte:

string name = @"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib";
string str2 = null;
int major = Environment.OSVersion.Version.Major;
int lCID = CultureInfo.InstalledUICulture.LCID;
if ((major >= 6) && (((lCID == 0x404) || (lCID == 0x804)) || (lCID == 0x416)))
{
    str2 = string.Format("{0,4}", lCID.ToString("X")).Replace(" ", "0");
}
else if (0x7c04 == CultureInfo.InstalledUICulture.Parent.LCID)
{
    str2 = "004";
}
else
{
    str2 = string.Format("{0,3}", CultureInfo.
           InstalledUICulture.Parent.LCID.ToString("X")).Replace(" ", "0");
}

Rode isso, o valor retornar em str2 é a chave que você precisa. Pelo que eu entendi, tem um tratamento especial para o Português brasileiro, que é o 0x416 em Hexa. Se for esse, ele chama a linha 7, senão ele chama a linha 15. O segundo elseif deve ser o do inglês, que retorna 004.

Enfim, espero que ajude quem está no enrosco nessa instalação.

Finalmente saiu o SQL Server 2008. Cheio de novidades, o novo SQL Server veio para consolidar um ótimo trabalho já feito no SQL Server 2005. Vêm novidades aí com a possibilidade de usar Hyper-V (a ser lançado em breve ao que tudo indica), suporte a dados espaciais e de localização, suporte a mais dados no Analysis Services, etc, etc, etc…

A Mary Jo Foley, da ZDNet, comenta as features um pouco mais aprofundadamente.

Se você ainda não viu o suporte a dados espaciais, sugiro dar uma olhada. As demos que já vi são sempre de cair o queixo, mostrando a distância entre as pessoas, localizando-as no mapa com Live maps, traçando rotas, enfim, o negócio é poderoso.

Hoje à noite ponho a mão nele. Vamos ver…

Estava precisando rodar um script em uma base de dados, e por acaso era uma User Instance, e não uma base padrão do SQL Server. Vocês se lembram o que é uma user instance, certo? É uma base que fica em um arquivo MDF solitário, que não está disponível através de uma conexão padrão do SQL. Ela deve ser anexada por um código .Net. São muito comuns em projeto web, principalmente de testes, e era este mesmo esse o caso. Eu tinha uma instância de usuário e precisava rodar um script:

Pois bem. Sapequei o Server Explorer do Visual Studio, achei a base, e selecionei "New Query"

Inseri o script. Foi pau atrás de pau. Pensei "Não é possível! Não dá para rodar scripts em user instances?" Dá. Veja só como:

Abra o SQL Management Studio ou a ferramenta que você achar melhor (não sendo o VS...). Conecte como admin em alguma base qualquer, pode até ser a master. Rode a seguinte query:

SELECT owning_principal_name, instance_pipe_name
FROM sys.dm_os_child_instances

Vai aparecer o seguinte nos resultados:

Essa string em instance_pipe_name é mágica. Coloque ela na string de conexão e voilà. Você está conectado:

Dêem uma olhada. A conexão aberta possui uma base de dados com um nome estranho. Essa é nossa base.

Atente que você pode ter problemas de conexão (por padrão terá). Isso pode acontecer porque o servidor não aceita conexões remotas. Para resolver, abra o surface area configuration (disponível no Start Menu), selecione "Service Area configuration for services and Connections" e ajuste para aceitar TCP e Named Pipes:

A partir daí é só rodar os scripts. Mais fácil impossível. Have fun!