fulvio

Bom dia Saphira, Segue link: http://www.sqlinsiders.net/?p=43

Qual opção você escolheu do shrink? Database ou Files?

Bom dia Matheus, Não conheço nenhuma função que formate os campos do excel via sql. Creio que a exportação entre os dois aplicativos sejam apenas uma comunicação simples, quer dizer: não conseguirá formatar dados no excel a partir do sql. Conheço via Visual Basic. Mas você tem q abrir a planilha do excel e passar comandos de VBScript para manipulação das tabelas.

Bom dia Saphira, Segue link: http://msdn.microsoft.com/pt-br/library/ms...SQL.110%29.aspx

Este foi um exemplo da implementação.... ai você terá q fazer as implementações devidas. Ainda acho mais fácil retornar todos os campos no resultset.... as manipulações e implementações poderão ser realizadas via código fonte.

Qual a ferramenta está utilizando?

Boa tarde WesSouza, Ficaria mais fácil você alterar o script e visualizar todos os dados de retorno.... Segue um exemplo com o loop: -- criando tabela create TABLE #Dados (id int identity, nome VARCHAR(15), valor int) -- inserindo dados INSERT INTO #Dados VALUES ('Elisabeth', 2443) INSERT INTO #Dados VALUES ('', 2443) INSERT INTO #Dados VALUES ('', 2443) INSERT INTO #Dados VALUES ('', 2443) INSERT INTO #Dados VALUES ('Rota', 1000) INSERT INTO #Dados VALUES ('', 1000) INSERT INTO #Dados VALUES ('', 1000) INSERT INTO #Dados VALUES ('', 1000) -- fazendo a somatória - selecionar até o final e executar DECLARE @Cont INT DECLARE @Nome VARCHAR(15) DECLARE @SubTotal INT DECLARE @Total INT SET @Cont = 1 SET @SubTotal = 0 SET @Total = 0 WHILE (@Cont <= (SELECT COUNT(nome) FROM #Dados)) BEGIN SET @Nome = (SELECT nome FROM #Dados WHERE id=@Cont) SET @SubTotal = @SubTotal + (SELECT valor FROM #Dados WHERE id=@Cont) SET @Total = @Total + (SELECT valor FROM #Dados WHERE id=@Cont) SET @Cont = @Cont + 1 SET @Nome = (SELECT nome FROM #Dados WHERE id=@Cont) IF @Nome <> '' OR @nome IS null BEGIN PRINT @SubTotal SET @SubTotal = 0 END END PRINT @Total

Vi a imagem em anexo... mas não entedi uma coisa: nas colunas Nome e Cod_Processo há campos em branco? No exemplo que passsei, não existem campos em branco. Por isso que o resultado sai ok. Se a sua base estiver da forma que postou na imagem, não terá jeito de fazer da forma que passei.... você terá que criar um loop para ir somando os campos, até encontrar um campo que tenha um nome diferente do q está somandom.

Bom dia NIK, Pode ter certeza que todas estes problemas existem sim... rs... independente da empresa que desenvolveu. A sua preocupação é válida. Prevenção é sempre importante. Uma proporção entre Banco X Memória infelizmente não existe, pois cada implementação possui sua particularidade. Nunca pesquisei, mas dê uma olhada na net que poderá encontrar estudos a respeito disso. Um exemplo: aqui trabalhamos com um banco específico que é mais ou menos 6 vezes maior que o seu. A modelagem e o aplicativo não são bem estruturados.... rs. A memória utilizada é cerca de 11 vezes maior que a sua (onde tivemos que aumentá-la). Mesmo tendo um software "fechado", há formas de monitorar suas atividades, como o Trace, tunig do sql, monitoramento de conexões por usuários, etc.

Boa tarde NIK, O uso de memória está associada basicamente a dois fatores principais: Acessos simultâneos (usuários) e aplicativo. Acessos simultâneos: quanto maior a quantidade de usuários simultâneos em seu banco, maior será o consumo de memória, uma vez que as conexões abertas e as transações executadas na base possuem correlação direta com a memória utilizada. Aplicativo: consultas mal feitas e recordsets não fechados são os principais "erros" encontrados em aplicativos. Quando falo em consultas mal feitas, estou me referindo aos "select * from ...." que o desenvolvedor utiliza para ganhar tempo, pois não precisará identificar os campos que realmente serão utilizados. Então o * trás tudo!!! rs. Poupa tempo também na hora de implementar novos campos, pois o recordset já está pronto!! Não precisará fazer nada para referenciar um novo campo. Isso faz com que a memória seja penalisada, pois terá mais dados inúteis "carregados". Quando falo em recordsets não fechados me refiro ao processo de: criação dos acessos, carga dos dados e, no final de sua utilização, o desenvolvedor esquecer de fechar e desalocar o espaço utilizado pelo recordset. Mas ai vem a dúvida: o escopo do recordset termina no escopo da função / implementação? Está correto!!! Mas a memória não é desalocada de imediato. Mas e os recordsets globais?? Vai ficar alocado até que o aplicativo seja finalizado. Quem fará a desalocação? O sistema operacional, quando precisar de mais espaço, ou periodicamente pelo garbage collector. Nesta situação, o garbage collector desalocará as memórias das variáveis globais e também das variáveis de escopo, caso ainda não tenha sido desalocada. Hoje a tecnologia está mais barata, ficando as vezes mais "fácil" resolver o problema via hardware. Mas se a análise não for realizada como um todo, o problema será apenas protelado... Estes dois pontos para mim são os mais críticos quando se refere a utilização de memória.

Sim, sem problemas.... Teoricamente está bem simples os selects. Mas o que vai diferenciar o uso de um ou de outro será mesmo a complexidade do select e dos dados de retorno em si. As vezes trabalhar passo a passo (criando temporárias) fica mais fácil o entendimento e manutenção. Segue o exemplo das duas formas que falei: --criação da tabela create table #Dados (Cod int, Depositante VARCHAR(10), Valor INT) --inserção dos dados INSERT INTO #Dados VALUES (123, 'Joao', 100) INSERT INTO #Dados VALUES (123, 'Joao', 110) INSERT INTO #Dados VALUES (123, 'Jose', 55) INSERT INTO #Dados VALUES (123, 'Jose', 60) -- 2 selects SELECT Depositante, SUM(Valor) FROM #Dados GROUP BY Depositante SELECT Cod, SUM(Valor) FROM #Dados GROUP BY Cod --utilizando uma temporária SELECT Depositante, SUM(Valor) Valor into #TabelaTemporaria FROM #Dados GROUP BY Depositante -- verificação da tabela criada SELECT * FROM #TabelaTemporaria -- realizando a soma SELECT SUM(valor) FROM #TabelaTemporaria

Deste jeito terá que fazer 2 selects. Um agrupando pelo depositante e outro agrupando pelo Cod. Outra alternativa é executar a primeira soma já criando uma temporária, e depois realizar a soma novamente a partir da mesma. Espero que ajude!! :.)

Boa tarde WesSouza, você pode utilizar a funçao SUM no valor que deseja somar e fazer o agrupamento pelo cod_processo.

Bom dia Alessandra, você está concatenando dois subselects, ok? No final do script tem a sintaxe from tab_horario. Comente esta parte e tente executar novamente.

Boa tarde Jonas, Na procedure você insere apenas 1 registro na tabela com identity? Se for, no final da procedure você pode dar um select max(id) from tabela para retornar o ultimo número incremental inserido. OBS.: - as procedures não são executadas em paralelo. Sendo assim, se der um max da coluna identity sempre retornará o número da ultima inserção. - apenas esta procedure poderá realizar este processo. Se tiver 2 procedures que insiram na tabela, poderá resgatar o número errado.

Boa tarde honda, SELECT name FROM sysobjects WHERE xtype='U'

Boa tarde Alessandra, Retire todos os alias que colocou e faça o teste.

Boa tarde Vanderlei, Seja bem vindo!! As tabelas que possuem mais registros são relativamente fáceis de conseguir. Pelo sysobjects dá para saber quais as tabelas existem na base (poderá utilizar um loop para executar e gravar os dados em uma tabela). Veja um exemplo: SELECT 'SELECT count(*) FROM ' + name FROM sysobjects s WHERE s.xtype='U' Quanto a quantidade de acessos, terá duas alternativas: - Verificar no código fonte todas as conexões à base, tentando identificar as tabelas (ou funcionalidades) mais referenciadas. - Fazer um monitoramento periódico na Base. Cuidado que o monitoramento realizado pelo sql consome processamento.... então identifique períodos específicos do dia para execução. Verifique junto aos analistas quais as funcionalidades mais críticas do sistema (as que causam mais preocupações), ou a entrada de dados inicial no sistema. Estas ai serão boas candidatas a uma análise...

Se quiser fazer diretamente no sql e o mesmo retornar os dados certinhos, terá q "programar" (da mesma forma que faria no código fonte). Terá que criar uma temporária, fazer um while (ou cursor) para testar linha a linha e ir concatenando os dados de acordo com o profissional. Será mais dificil e trabalhoso, mas retornará o que deseja.

Boa tarde Alessandra, Da forma que realizou o select, não tem como fazer a concatenação. Utilizando case, o resultado "entrará" apenas em uma das cláusulas... Você consegue manipular o resultado do select em algum aplicativo? Estou peguntando pois algumas implementações são bem mais simples (e rápidas) nos códigos fontes, do que no sql. Não sei para que serviria este resultado (visualização em aplicativo, estatistica, relatório, etc), mas preferiria retirar os cases e passar para o fonte este tratamento: - Os dias da semana seriam retornados como números mesmo, onde o código fonte colocaria os escritos. - Os horários viviriam do jeito q postou, mas testaria: se o professor for o mesmo, concatenaria os horários. As plataformas de desenvolvimento possuem funcionalidades mais voltadas a implementações, havendo mais recursos do que o sql.

Bom dia Cleiton, Desta forma não tem como fazer.... mesmo criando uma variável e tentando executar o string. você pode criar a coluna como varchar que comporte "todos" os formatos de tamanhos. Aí a manipulação será de acordo com os dados inseridos. Dados com 7 posições teria o @TAMANHO_FIXO = 7, por exemplo...

Bom dia Cleiton, Ok, entendido... rs. Mas não seria mais interessante passar o tamanho do campo e fazer a manipulação com este valor? As vezes o exemplo abaixo possa ajudar... DECLARE @TAMANHO_FIXO INTEGER SET @TAMANHO_FIXO = 7 SELECT REPLICATE('0', @TAMANHO_FIXO - LEN(456)) + CAST(456 AS varchar)

Boa tarde Cleiton, Desculpe pela pergunta, mas por que deseja fazer um campo de tamanho variável?

Boa tarde Diogo, Acrecentando apenas mais algumas coisas: Sua pergunta: Como endereço é único, ele fica na tabela cliente certo? Na modelagem em si, os dados de endereços não são dados "pertencentes" aos clientes. Estes dados estão relcionados a um lugar físico (logradouro, cep, complemento, ponto de referência, etc). Prefira criar uma tabela Endereço. Nela você fará um relacionamento com a tabela de Cliente. Desta forma, conseguirá colocar na nova tabela de Endereço não somente os endereços de clientes, mas também de fornecedores, serviços, etc. O endereço de clientes NÃO é único. No levantamento de requisitos, poderá sim ter esta regra que identifique este relacionamento. Mas perceba: e se o cliente tiver endereço de casa e de trabalho? :.) Espero que ajude....

Bom dia peneju, Esta sintaxe pode funcionar sim, mas o sql não conseguisrá identificar uma cronologia.... Um exemplo: Pegar a quantida de inserções entre 20-11-11 e 10-12-11. você terá um grande problema com o campo DIA, pois terá que pegar os dias maiores que 20 e menores que 10. Perceba que pensando em data, a idéia está correta. Mas pensado em apenas números inteiros, o interavalo lógica está incorreto. O resultado não será correto. Terá q levar em consideração o mês. Assim ficará mais fácil a concatenação dos campos em datas. A pesquisa será bem mais direta e simples!! :.)