Vitor Rubio Developer - Dicas de programação

O SQL 2012 e superior tem a função DATEFROMPARTS para criar uma nova data a partir dos inteiros Ano, Mes e Dia, mas as versões 2000, 2005 e 2008 como é que fica? Fica assim: você mesmo faz a função. SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO -- ############################################################################################################################################ -- # NOME : DATEFROMPARTS -- # PRODUTO : SQL Server -- # DEVELOPER : Vitor Luiz Rubio -- # COPYRIGHT : -- # OBJETIVO : Gerar uma data a partir dos seus componentes inteiros -- # VERSAO : 1.0 -- # DT. CRIACAO : 2013-04-18 -- # DT. ALTERACAO : -- # -- # DEPENDENCIAS : -- # -- # DEPENDENTES : -- # -- # HISTÓRICO -- # 2013-04-18 : Criação -- # -- ############################################################################################################################################ CREATE FUNCTION DATEFROMPARTS ( @Year int, @Month int, @Day int ) RETURNS datetime AS BEGIN --da...

De tempos em tempos precisamos fazer aquele processamento que só pode ser feito em dias úteis. Seja a data de pagamento de um boleto, o agendamento de uma entrevista e assim por diante. O desafio disso está no fato de que temos feriados nacionais com dia fixo, feriados com dia variável porém computável (através de algoritmos) e feriados municipais. Os municipais não tem outra forma de atender senão consultando uma tabela do banco de dados pelo código do município, mas os feriados nacionais fixos nós podemos dar uma bom começo. Segue abaixo a função fn_dia_util que retorna 1 se o dia for útil e 0 se for sábado, domingo ou feriado (usando a função weekday para isso) e a função fn_proximo_dia_util, que verifica se o próximo dia é util e se não for vai acrescentando um em loop. Mesmo se o feriado cair numa sexta-feira ela retornará o próximo dia útil. -- ##############################################################################################################################...

Lidando com bancos de dados podemos controlar as transações e a maneira como podemos acessar os dados em transações concorrentes. Os níveis de isolamento de transação e os comandos para tais serão discutidos em um próximo post, porém, resumidamente, temos (Serializável, snapshot, repeatable read, read commited, read uncommited). Dirty read (read uncommited ou nolock) nos permitem visualizar os dados de uma tabela mesmo sendo sujos (alterados em outras transações). Isso garante, com certo nível de inconsistência se as transações forem desprezadas e o  rollback usado, uma leitura o mais rápido possível dos dados no seu estado atual quase que em tempo real. No entanto, como separar os dados "sujos" daqueles que já estavam gravados e commitados? Imagine que você tem um ambiente onde um sistema legado permite que a aplicação seja fechada, após uma exception ou queda de rede, sem dar commit ou rollback nas transações correntes. Você rapidamente ficaria com várias transações...

Dentre os problemas mais recorrentes em sistemas podemos citar os relacionados à cultura: charset, datas e formatação de números. Datas são especialmente problemáticas porque podem ser ambíguas dependendo da cultura, por exemplo 02/01/1990 pode ser dois de janeiro no Brasil ou primeiro de fevereiro nos EUA. Ainda mais agravante é o fato de nem sempre podermos validar as datas nos imputs, pois as mesmas podem vir de arquivos de integração, outros sistemas, CSV, TXT, Excel ou webservices. Pensando nisso eu fiz uma pequea demonstração do uso dos comandos cast e convert para converter varchar para datas e datas para varchar, e mostrando onde estão os erros mais comuns. /******************************************************************************************************* ******************************** DEMONSTRAÇÃO DE CONVERSÃO DE DATAS ************************************ ********************************************************************************************************/ --i...

Li alguns artigos sobre a diferença entre Log Shipping, Mirroring e Replication e gostaria de compartilhar. http://www.replicationanswers.com/ReplicationLogShippingMirroring.asp Difference between Log Shipping, Mirroring and Replication http://simplesql.blogspot.com.br/2011/01/replication-vs-mirroring-and-what-to.html Basicamente, o Log Shipping é uma estratégia só de Disaster Recovery, mas não muito eficiente para relatórios ou replicação/distribuição dos dados. Ele nada mais faz do que restaurar em uma outra base os logs de transação periodicamente. Esta base fica com lock exclusivo, então consultas nela só podem ser feitas usando-se nolock (dirty reads) ou isolation level snapshot. Log Shipping restaura o banco inteiro, inclusive tabelas de sistema, views, procedures etc. Mirroring também é uma solução para Disaster Recovery e funciona para o banco todo, inclusive dados de sistema. Sua vantagem é que pode ser configurado com failover automático, ou seja, para entrar no ar as...