domingo, 2 de maio de 2010

Cosinhas legaizinhas no SQL Server

Descobri que mesmo para um desenvolvedor Genexus, Java, NET, ... é necessário conhecer macetes a respeito de todo ambiente onde sua aplicação está rodando, isso te ajudará a sair de certos incêndios.

Em ambientes corporativos as tarefas são normalmente designadas para pessoas diferentes, devendo ocorrer o contato/solicitação para que alguma situação em sua área seja resolvida por um gênio de outra área, levando a muita especialização em um único assunto.

Um bom desenvolvedor Genexus consegue conciliar o conhecimento profundo na ferramenta com o essencial para sobreviver no ambiente em que a aplicação está executando (compilador, linguagem, banco de dados,  servidor web, ....,  ), já um desenvolvedor Genexus eficiente e flexível busca conhecer muito sobre o entorno da aplicação, pois sabe que isso o levará a criação de sistemas muito mais eficientes, com utilização de todos os recursos que a tecnologia oferece.

Aviso! Não tenho tido muito tempo para me aprofundar no Microsoft SQL Sever, e se esse for seu caso, por favor não continue a ler este blog, pois me achará meio ignorante nisso, o que é pura verdade!.

Então, para os que estão começando a compreender o SQL Sever, como eu, vamos lá!

Como copiar todos os dados de uma tabela em outra, mas em bancos diferentes
Essa pode te salvar quando é necessário dar um Create Database no Genexus, e voce não pode perder dados que se encontram em uma determinada base de dados. Nesse caso voce pode criar uma nova database para a aplicação, mantendo a antiga intacta e em seguida realizar a operação de carga da antiga para a nova.

INSERT INTO tabela_destino     SELECT  * FROM  db_fonte..tabela_fonte

Nesse caso a estrutura (ordem e numero de atributos) da tabela_destino deve ser a mesma da tabela_fonte, e observe que a query está rodando a partir da database_destino.

Como copiar alguns atributos de uma tabela em outra, mas em bancos diferentes
Essa pode te salvar quando ocorreu mudança estrutural entre a tabela_destino e a  tabela_fonte, mas a fonte possui a maioria da informação que voce necessita para carregar 'inicialmente' a tabela_destino.

INSERT INTO tabela_destino  (atr1, atr2, atr3)   SELECT  atr1, atr2, atr3 FROM  db_fonte..tabela_fonte

Nesse caso a ordem dos atributos da tabela_destino deve ser a mesma da lista selecionada na tabela_fonte, e observe que também a query está rodando a partir da database_destino.

Como copiar desligando o identity
Quando ocorre mudança estrutural entre a tabela_destino e a  tabela_fonte, é possível copiar parte da informação, mas o problema é sincronizar os valores das chaves numéricas que foram definidas como Autonumber=yes, ou seja, com Identity=Yes.

SET IDENTITY_INSERT tabela_destino ON
INSERT INTO tabela_destino  (atr1, atr2, atr3)   SELECT  atr1, atr2, atr3 FROM  db_fonte..tabela_fonte
SET IDENTITY_INSERT tabela_destino OFF

Nesse caso a ordem dos atributos da tabela_destino deve ser a mesma da lista selecionada na tabela_fonte, e observe que também a query está rodando a partir da database_destino. O atributo atr1 é chave e é normalmente designado como IDENTITY=YES.


Alterar valor do contador IDENTITY
Para posicionar o contador do autonumber para um valor especifico execute:
DBCC CHECKIDENT('tabela_destino', RESEED,


Agradeça ao meu amigo Claudio Shinji, pela ajuda nesse blog, ok!