Alexsandro Haag - Sharing knowledge

   Nestes dias ao configurar um dump de dados de determinado cliente percebi que o processo estava demorando demais. Sendo assim abri o arquivo de log do dump e percebi que estavam sendo exportadas diversas tabelas CCMC (Movimentos Contábeis) que, por padrão, são sufixadas pelo ANO corrente e são criadas já algumas para alguns anos a frente. Como por exemplo CCMC2010, CCMC2011, CCMC2012, etc...    O porém disso tudo é que, nesta base especificamente, foi realizada uma criação de diversas tabelas com vários anos a frente. Chegando até o ano de 9999. Além de vários anos que antecediam até a própria idade da empresa. Apesar destas tabelas estarem vazias elas ocupam espaço no banco de dados, além de tornarem o processo de exportação/importação de dados muito mais demorado.     Como remover uma a uma daria bastante trabalho montei o script abaixo para gerar como saída o comando de exclusão de cada uma destas tabelas com anos tão altos. O script ficou ass...

Os campos do tipo "Date" nas tabelas do CIGAM, como regra, salvam somente a data sem o horário nos registros. Quando realizamos alguma operação de insert/update diretamente pelo banco de dados é necessário que façamos uma adequação deste tipo de campo para não gravar o horário junto (padrão dos bancos de dados Oracle e MSSQL).   Os comandos que podemos usar para gravar da forma correta são os seguintes: Para Oracle:   Obs.: Como vimos bastante simples, basta usar a função "trunc" de sysdate (que retorna a data atual) ou do campo de tipo date que quisermos ajustar. Para MSSQL:   Obs.: Para MSSQL como podemos observar acima é um pouco mais complicado de converter, já que não existe a função trunc para datas. Desta forma se faz necessário utilizarmos uma combinação de funções de conversão: cast(floor(cast(getdate() as float)) as datetime). Bom, trata-se de um post bastante simples, com o intuito de ajudar nestas situações onde podemos perder um certo tempo ten...

Recentemente precisei conectar ao PostgreSQL para um projeto de Integração do CIGAM com um outro sistema utilizado por um de nossos clientes. O procedimento que utilizei foi o seguinte: Baixei e instalei o driver ODBC do Postgres a partir daqui ; Criei uma nova conexão ODBC de sistema utilizando o driver recém instalado; Fiz a configuração conforme mostrado na figura abaixo:    Fiz o teste de conexão para verificar se conseguia acessar o banco de dados do outro sistema, que retornou sucesso:   Para garantir maior segurança coloquei como preferencial o uso de SSL:     Novamente testei a conexão e verifiquei que estava funcionando:    Após constatar que a conexão ODBC estava correta parti então para montar o projeto no iBolt; Configurei a conexão com o PostgreSQL utilizando o DBMS "ODBC" e informando no "Data Source Name" o mesmo nome utilizado previamente na criação da ODBC, conforme exibido na figura abaixo:   Utilizando o botão "Validate...

Quando utilizo a VMWare Server 2.0 como opção de ferramenta de virtualização realizo sempre alguns ajustes básicos, mas que normalmente melhoram bastante o desempenho geral da solução. Vou descrever abaixo os itens que ajusto: O primeiro item que altero a gravação em disco para o modo assíncrono. Isso é o que normalmente dá um ganho imediato perceptível. Troco do modo padrão "Optimize for Safety" para o modo "Optimize for Performance": Outra coisa é desabilitar os logs de runtime da VMWare. Isso não é recomendado pelo fabricante, e também não impacta muito no desempenho geral se estiver habilitado, mas mesmo assim costumo desabilitar e não tem me feito falta. Lembrando que, em momento oportuno sempre é possível marcá-lo novamente. Também forço o uso de um recurso chamado "Virtualized MMU" ao invés de deixar que o Host determine automaticamente. Claro que se a CPU não prover este recurso então esta configuração simplesmente não trará efeito algum. Neste ...

  Dia destes precisei gerar um script de todos os índices de determinado esquema para executá-los em outro banco de dados em cliente, com o intuito de recriar os índices ausentes na base. Para isso então criei uma procedure que faz um output do script dos índices. Fiz ela conforme abaixo... create   or   replace PROCEDURE   GERA_INDICES_CIGAM   ( p_owner   varchar2   default   'CIGAM' ) AS /* Procedimento criado para gerar script de criação de indices de um esquema    para aplicar em outro.        Criado por: Alexsandro Haag     Criado em: 2010-09-23 (AAAA-MM-DD)    Alterado em: 0000-00-00 (AAAA-MM-DD) */ /*Crio cursor com todos os indices do esquema escolhido*/ cursor   c_indices   ...

Complementando o post anterior, segue agora a procedure da geração dos alertas em MSSQL: SET   ansi_nulls    OFF   GO   SET   quoted_identifier    OFF   GO   CREATE   PROCEDURE   cgpr_utl_criaalerta (                    @assunto   VARCHAR ( 300 )    =   'TESTE' ,                   @cd_usu_aviso   CHAR ( 3 )    =   'SQL' ,                   @dt_previsao_ini   DATETIME    =   NULL ,                   @hr_previsao_ini   CHAR ( 6 )    =   NULL ,                  ...

Faz algum tempo, venho comentando com alguns colegas de trabalho sobre como seria útil enviar mensagens para os usuários do CIGAM através do cadastro de alertas via rotinas do banco de dados. Dentre as possibilidades imaginadas, poderia servir por exemplo, para informar ao usuário que seu banco de dados Oracle-XE está chegando muito próximo do seu limite de utilização de 4GB. Ou ainda que faltam X dias para a licença de demonstração do CIGAM expirar. Talvez também alguma informação de negócio, como que determinado cliente estourou seu limite de compra. Ou que o estoque mínimo de certo material foi atingido. As possibilidades são muitas, mas hoje surgiu uma real, que motivou a implementação deste recurso. O usuário gostaria de ser informado se fosse digitado algum pedido para algum cliente que não tivésse um email cadastrado, pois agora, com a Nota Fiscal Eletrônica, esta informação é obrigatória. A partir daí a primeira coisa que fiz foi criar a procedure que cadastra o Alerta, da s...