Leandro Ribeiro

Muitas pessoas já passaram pelo problema de não conseguir inserir arquivos de dados (mdf) na pasta App_Data do Visual Studio 2005/2008 ou até mesmo 2010.

A mensagem que costuma aparecer é a seguinte.

“Connections to sql server files (*.mdf) require sql server express 2005 to function properly. Please verify the installation of the component or download from the url: http://go.microsoft.com/fwlink/?LinkId=49251″

Muitas soluções são propostas pela internet, mas a solução definitiva é mais simples do que se pensa.

Acontece que a maioria das pessoas alteração o nome da instância do SQL Server instalada, por exemplo, quando você instala o SQL Server Express 2008 é costuma colocar o nome da instância como SQLEXPRESS2008 ou quando é o SQL Server Express 2005 fica SQLEXPRESS2005.

Quando você faz essa alteração o Visual Studio “fica cego”, eu acho que isso é uma falha grosseira na implementação do Visual Studio, mas não vamos entrar no mérito da questão, eis a alteração necessária para corrigir o problema.

Tools > Options > Database Tools > Data Connections

Em SQL Server Instance Name digite o nome correto da sua instância, no meu caso ficará SQLEXPRESS2008.

Antes (clique na imagem para ampliar)

Visual Studio 2008 Database Settings

Depois (clique na imagem para ampliar)

Visual Studio 2008 Database Settings

Pronto agora você já pode adicionar seus arquivos de dados na pasta App_Data do seu WebSite.

Espero que tenha ajudado!

att.
Leandro Ribeiro

Camaradas,

Recentemente precisei descobrir qual o nome da instância do SQL Server instalada na máquina de um cliente meu, só que meu cliente não sabia como buscar essa informação.

Eu já conhecia o utilitário de linha de comando do SQL Server (sqlcmd) , só que até então só sabia utiliza-ló acessando através do usário e senha.

Pois então eu descobri que existe o parametrô -L, que exibe os nomes das instâncias instaladas na máquina.

Basta então utilizar o prompt de comando, digitando SQLCMD -L e você terá um resultado semelhante a esse.

Refêrencias:
http://mssqlonline.blogspot.com/2009/03/sql-server-find-all-servers-from-local.html
http://blog.sqlauthority.com/2009/03/18/sql-server-find-all-servers-from-local-network-using-sqlcmd/

Até a próxima!
Leandro Ribeiro

Há quem goste de fazer tudo por interface gráfica, porém ao fazer dessa forma você perde a oportunidade de automatizar tarefas, por exemplo dizer que você tenha que criar 30 usuários, você irá fazer tudo manualmente ?

Eu prefiro script assim toda vez que eu precisar basta mudar o login e pronto, está feito!

Segue um script de exemplo.

Nesse exemplo eu estou criando o usuário e dando acesso de (INSERT, UPDATE, SELECT, DELETE) através das ROLES ‘DB_DATAREADER’ e ‘DB_DATAWRITER’.

Código Exemplo

CREATE LOGIN usuario1
WITH PASSWORD = 'usuario1'
GO 

USE [TesteBD]

CREATE USER usuario1 FOR LOGIN usuario1
WITH DEFAULT_SCHEMA = [TesteBD]
GO

EXEC SP_ADDROLEMEMBER 'DB_DATAREADER', 'usuario1'
EXEC SP_ADDROLEMEMBER 'DB_DATAWRITER', 'usuario1'

GO

Divirta-se!

Script simples porém muito útil então resolvi postar.

Não me recordo da fonte…
Quando relembrar faço referência.

SELECT OBJECT_NAME(ID) TABELA, CONVERT(DEC(15),SUM(RESERVED)) RESERVED
INTO #X
FROM SYSINDEXES
WHERE indid in (0, 1, 255)
GROUP BY ID

SELECT TABELA, LTRIM(STR(RESERVED * D.LOW / 1024., 15, 0)) + ' KB'
FROM #X, master.dbo.spt_values d
where d.number = 1
and d.type = 'E'
ORDER BY RESERVED DESC

Divirta-se!

Recentemente trabalhei em um projeto de milhões de dados, tanto no ambiente de desenvolvimento ou de produção.

O resultado foi que em algumas semanas o servidor de desenvolvimento “estourou”, metaforicamente falando claro. Identificamos que as bases de dados estavam com 30GB cada uma, resultado de uma má estratégia de modelo de recuperação (backup).

Procurando na internet encontrei um artigo interessante sobre o assunto, pode ser lido em: www.devmedia.com.br/articles/viewcomp.asp?comp=6458

O resumo seria o seguinte…

SIMPLE (Ideial para Desenvolvimento!)

O log de transações (Transaction Log) é usado muito pouco neste modelo de recuperação. De fato, quase nada é registrado no log. Isto significa dizer que a escolha em usar este modelo para seus banco de dados só será possível recuperar o último backup.

BULK-LOGGED

Este modelo registra muito mais informação no log de transações do que o modelo SIMPLE. A única informação não registrada são operações de volume como: SELECT INTO, BCP, BULK INSERT,CREATE INDEX e operações com os tipos de dados texto e ntext. Isto significa que você pode recuperar a maior parte dos dados no caso de algum problema, porém só as operações citadas serão perdidas.

FULL (Sempre em produção!)

Este modelo de recuperação informa ao SQL Server que você quer realizar também o backup de log de transações. Para tornar isso possível, o SQL Server mantém todas as transações em um log de transações até que um backup do log de transações ocorra. Quando o backup do log de transações acontece, o SQL Server trunca o log de transações depois que o backup é gravado no dispositivo de backup.

Fonte:
www.devmedia.com.br/articles/viewcomp.asp?comp=6458