Emanuel Peixoto

Dê uma pesquisada sobre collation.

O objetivo das triggers é bem claro, é dar suporte as regras de negócio independente da aplicação, ou seja, é um recurso fenomenal. No caso, da aplicação revove-la quando são realizados os updates de versões isso é uma falha do sistema. Ora, se o banco de dados é um componente independente da aplicação, o que no máximo poderia acontecer era a alteração e adição de objetos nunca remoção, pois, o banco de dados não é proprietário do sistema X, Y ou Z, ele é independente. imaginem a situação: Um grande companhia compra a solução RM, e implanta um recurso de replicação de dados dos sistemas entre a matriz e as filiais baseada em de triggers, num sei nem se a RM já possui um recurso para esse tipo de situação... se, quando eu fizer uma atualização de versão e isso me gerar incidentes na infra-estutura de banco de dados e nas regras de negócio devido ao sistema remove-las, isso é certo? O banco de dados não é indepenente? o sistema está respeitando isso? "Usar ou não triggers...." vai depender da necessidade, ora se eu escolher usar triggers e se dessa forma for mais flexivel, rápido de desenvolver ou até mesmo realizar operações de integração entre sistemas de forma que de outro jeito não iria funcionar, porque não usar? SIM, ao uso de triggers.

O que eu vejo é que provavelmente o protocolo named pipes não está ativa do no servidor(SQL 2005). http://www.developer.com/db/article.php/3496511

sim.

Todos os S.O's "desktop" microsoft possuem limitação de 10 conexões simutaneas por padrão. Lí uma vez que tem como burlar essa limitação de conexões simutaneas via registro. Dá uma procurada no Google.

Não existe uma função pra fazer isso que vc quer, mas, vc pode jogar esses dados em uma tabela temporária, limpar os valores que vc não deseja e deixar apenas a primeira linha. use essa tabela temporária(tratada) para aporesentar os dados da forma que vc deseja.

Lembrese que o distinct só resolveu devido a o retorno do select só ser de um valor do codtmv, sempre retornando 1 registro.BLZ! Em circunstancia diferentes, mesmo com o distinct se for retornado mais de um codtmv, o erro acontecerá novamente.

Qual é o build do SQL que vc tem aí? vc é a segunda pessoal que eu vejo ter esse tipo de problema, vou tentar verificar uma solução pra vc. A principio acho isso anormal, mas, como eu ainda não tive muito contato com o Windows 2008 não tenho certeza do que pode ser. me informa o build. Select serverproperty('productlevel') as produto, serverproperty('edition') as edicao, serverproperty('productversion') as Versao

Olá Marco, acredito que a falha esteja na abertura da trigger, na primeira condição(IF). Faz o seguinte: troque a condição -->> if (select codtmv from inserted) < '1.2' and (select status from inserted) = 'F' por um "if exists", que permitirá mais de um valor para comparação da condição. Ficando assim: if exists(select 1 from inserted where codtmv < '1.2' and status= 'F') begin ......

A quantidade de bases não influencia na performance.

Use o profile para capturar os comandos repassados pelo acesso do cubo à sua base, depois utilize o Index Tuning wizard(SQL2000) ou o DTA(SQL2005) que sugere ou cria indices e estatísticas automaticamente. Outra coisa que vc pode estar vendo é a possibilidade de habilitar o trace flag 9059 caso vc utilize muitas agregações no teu cubo. dá uma olhada no link abaixo: http://support.microsoft.com/kb/899976

Num é dica não Galdino, é um conceito correto sobre o assunto. Ter alguns coiceitos básicos bem abrendidos é muito importante. Gostaria de ter mais tempo pra compartilhar mais coisas com vcs aqui no formula. Costumo acessar vez em quando, tem muita coisa boa que eu pesco daqui.

Galdino, vou te dar uma explicação sobre indices e estatisticas que deve esclarecer e te dar um conceito correto. Os indices de uma tabela são como os indices de um livro, eles indicam onde encontrar o que vc está procurando. O SQL permite vc a criar vários indices em uma mesma tabela, de forma que vc pode organizar os dados na ordem que vc quizer, exemplo: se vc cria um indice que organiza os dados por data, no momento que vc realiza consultas por data o resultado será o melhor possível, pois o sql irá utilizar o indice que vc criou por data. Se vc criar outro indice que organiza a tabela por codigo do movimento, quando vc realiar consultas que pesquisem por ordem de codigo de movimento, a consulta irá ser rápida pois os indices irão apontar para as informações de forma correta. Mas, como o SQL sabe qual indice utilizar quando vc está realizando uma consulta em uma tabela que possui mais de um indice?? Resposta: ESTATISTICAS!!! As estatisticas são contadores que informam para o SQL quais são os melhores indices ou os indices mais rápidos. O SQL sabe quais são os melhores indices baseado num contador sobre os campos que compoem os indices, os indices que possuem campos com maior seletividade são escolhidos e a consulta executa feito uma BALA!!! Para isso, vc deve criar estatisticas para os indices, não adianta vc ter indices sem estatisticas. Realizando uma verificação do plano de execução de qualquer consulta vc pode verificar a inexistencia de indice e criá-los. Outra forma é o Index Tuning wizard(SQL2000) ou o DTA(SQL2005) que sugere ou cria indices e estatísticas automaticamente. O FullScan comentado pelo colega Mafra só é realizado quando não existem indices para os dados que estão sendo pesquisados, quando as estatisticas não existem, são ineficientes ou estão desatualizadas. Pra vc ver como a falta de estatisticas é crucial pra imagine a seguinte situação: vc chega em uma biblioteca e vai procurar o assunto "Atualização de estatisticas" pesquisando nos indices de todos os livros de informatica relacionados com banco de dados, até vc encontrar um livro que tenha o assunto no indice pode demorar bastante. apesar de todos os livros possuirem índices isso não quer dizer que vc irá encontrar rapidamente o que vc quer. Agora se a bibliotéca possui um estatistica, onde, vc pode realizar a seguinte consuta: quais os livros que possuem o assunto "Atualização de estatisticas" no indice? se existir essa estatisticas vc irá direto para os livros certos, sem perder muito tempo. Agora, se por acaso, não existirem as estatisticas, vc até pode encontrar os livros que contem o assunto, porém, se não existir nem estatistica e nem indices, vc estárá perdido!! coitado de vc, terá que verificar todas as folhas de todos os livros para encontrar o assunto "Atualização de estatisticas",rsrsrsrs. Tão importante quando criar indices e estatisticas é a manutenção delas, realize diáriamente reindexação dos indices de todas as tabelas e atualize as estatisticas também para todos os objetos.

Primeira coisa, verifique a permissão NTFS. Certifique-se que o usuário de serviço do SQL possui permissão total sobre o MDF. caso a conta de serviço do SQL esteja configuradao para local system, então, configure o mdf para ter acesso total para everyone e/ou system. Outra coisa, a permissão não é só no arquivo não, a conta deve ter acesso no caminho todo até o arquivo.

Olá João, o comando é o SQLCMD.