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!