quinta-feira, 8 de agosto de 2013

XML no SQL Server


O método escolhido pelo SQL Server 2000 para permitir modificações em dados usando documentos XML é usando o data source OPENXML. Esta função prove a visualização dos dados em rowset.
Para usar o data source XML com T-SQL, o documento precisa ser validado e armazenado na memória em uma representação de árvore. Esta árvore representa as informações de cada nodo que o SQL Server 2000 terá que saber para preparar a linha de leitura.
No SQL Server 2000 existe uma stored procedure, chamada sp_xml_preparedocument, que irá converter o documento XML para ser representado internamente pelo SQL Server 2000.

SP_XML_PREPAREDOCUMENT


O OPENXML não pode trabalhar com uma string formatada em XML. O OPENXML vai ler os dados já devidamente formatados, pode ele não interpreta a estrutura de nodos. Por este motivo usamos o SP_XML_PREPAREDOCUMENT para converter o documento em um padrão que o SQL Server 2000 possa ler e interpretar.
Esta stored procedure cria uma representação temporária na memória com o formato de uma view.
A figura abaixo exibe uma estrutura de um documento XML usado em nosso exemplo.














Já a figura abaixo mostra como o SQL Server lê as informações depois que o documento passar pela stored procedure SP_XML_PREPAREDOCUMENT.










Segue a baixo o codigo para fazer a importação dos dados.

O código abaixo mostra como fazer uma importação do conteúdo XML para dentro de uma tabela temporária chamada #funcionario, a partir desta tabela é só copiar os dados de uma tabela do SQL Server para outra tabela. Não existe mistério nisso.

Segue durante o código o comentário de cada linha e comandos do SQL Server. 
















































Observação: nunca esqueça que é muito importante remover o conteúdo do documento XML da memória. 

bom pessoal espero que tenha ajudado alguém, e como sempre !!

clica, clica, clica...rsrsrs

segunda-feira, 22 de julho de 2013

Cursores SQL Server

Boa tarde a todos,
vamos aprender hoje um pouco sobre cursores no SQL Server, uma ferramenta muito boa, que soluciona varios problemas, mas dependendo da situação pode ser custosa, então antes de usar analise bem se é realmente necessário.

Entendendo os Cursores


O SQL Server suporta dois tipos de cursores: os cursores T-SQL e os cursores API (Application Programming Interface). Neste artigo falarei dos cursores do tipo T-SQL, isso porque para utilizarmos um cursor API teremos que ter a documentação apropriada de cada API que será utilizada, ou seja, os cursores do tipo API são específicos de cada API.

Os cursores T-SQL são criados usando o comando DECLARE CURSOR. Quando estamos utilizando um cursor a partir de uma aplicação conectada a um servidor Microsoft SQL Server, cada operação no cursor requer uma viagem de ida e volta através da rede.

O conjunto de linhas para o qual um cursor aponta é definido pelo comando SELECT. Existem algumas restrições SELECT ao se criar um cursor T-SQL:

. Não poderá retornar vários conjuntos de linhas.

. Não poderá conter a cláusula INTO para criar uma nova tabela.

. Não poderá conter a cláusulas COMPUTE ou COMPUTE BY, contudo poderá conter funções agregadas, tais como AVG.

Vamos analisar algumas características dos cursores e para não confundir muito dividirei em três grupos de cursores pelas suas características:

. Capacidade de refletir alterações em dados subjacentes.

. Capacidade de rolar pelo conjunto de linhas.

. Capacidade de atualizar o conjunto de linhas.

Refletindo alterações

Se criarmos um cursor com a instrução abaixo:

SELECT * FROM rg_cidade WHERE nmcidade LIKE '%i%'

O banco de dados irá retornar algo similar à imagem abaixo.


                                 Imagine se alguém alterar a linha do registro ‘Farroupilha’ o que acontecerá com o conjunto de dados
apontados pelo cursor?

Existem dois tipos de reflexos que podem ser determinados separadamente quando você criar o seu cursor:


. Alterações nas quais as linhas estejam incluídas no conjunto

. Alterações nos valores das linhas subjacentes.

Rolagem

Outra característica é se você poderá utilizar o cursor para rolar para frente e para trás ou somente para frente. Aqui encontraremos o velho dilema velocidade X flexibilidade. Os cursores que vão apenas para frente são significativamente mais rápidos, mas menos flexíveis.

Atualização

Por último, é se as linhas podem ser atualizadas pelo cursor. Mais uma vez, os cursores de somente leitura geralmente são mais eficientes, porem menos flexíveis.

Tipo de cursor

O T-SQL suporta quatro tipos de cursor diferentes:

. Static

. Keyset

. Dynamic

. Firehose

Cada tipo de cursor armazena os dados de maneira diferente e cada um suporta diferentes tipos de combinações de características descritas anteriormente. Veja a descrição de cada tipo de cursor abaixo:

Static: os cursores static fazem uma cópia dos dados especificados pela instrução SELECT e a armazena no banco de dados tempdb. Este tipo de cursor não permite alterações nos valores de associação ou dados, como qualquer atualização refletiria apenas uma cópia, este tipo é sempre somente leitura. Static podem, contudo ser declarados como forward-only (apenas para frente) ou scrollable (roláveis).

Keyset: um cursor keyset copia para o tempdb apenas as colunas necessárias para identificar exclusivamente cada linha. Para declarar um cursor deste tipo, cada tabela envolvida na instrução SELECT de definição deverá ter um índice exclusivo que defina o conjunto de chaves a ser copiado.

Os cursores keyset podem ser updatable (atualizáveis) ou read-only (somente-leitura) e também scrollable (roláveis) ou forward-only (apenas para frente).

Um cursor keyset é fixado quando você declara o cursor. Se uma linha que satisfaça as condições selecionadas for adicionada enquanto o cursor estiver aberto ela não será adicionada ao conjunto de dados.

Embora a associação na definição do cursor seja fixada quando você abre o cursor, as alterações aos valores de dados nas tabelas subjacentes geralmente são refletidas. Por exemplo, as alterações para o valor nmcidade da linha “Farroupilha” seriam retornadas pelo cursor. As alterações para os valores definidos por chaves, contudo refletirão no cursor apenas se forem feitas pelo cursor. Para continuar o exemplo anterior, se o valor fosse alterado pelo cursor, este retornaria, então, o valor alterado. Porém, se a alteração fosse feita por outro usuário, este cursor continuará retornando o valor anterior.

Dynamic: um cursor dynamic comporta-se como se uma instrução SELECT fosse lançada novamente sempre que uma linha fosse referenciada. Os cursores Dynamic refletem as alterações de valor tanto da associação quanto dos dados subjacentes, quer essas alterações tenham sido feitas pelo cursor ou por qualquer outro usuário.

Firehose: Esse tipo de cursor é declarado usando FAST_FORWARD, mas é mais conhecido como um cursor firehose. Existem duas restrições importantes quanto ao seu uso.

. Se a instrução SELECT que define o cursor faz referencia a colunas do tipo text, ntext ou image e contiver a cláusula TOP, o SQL Server converterá o cursor firehose em um cursor keyset.

. Se a instrução SELECT combinar tabelas que contenham triggers o cursor será convertido para static.

Criando cursores

Para criar um cursor, utilizamos a instrução DECLARE CURSOR. A sintaxe da instrução DECLARE CURSOR copiada do Books Online é:  
                          Veja abaixo a explicação para cada linha da instrução acima:

01. É usado para definir o escopo do cursor assim como funciona em tabelas temporárias (@local ou @@global).

02. Indica a rolagem a ser definida para o cursor e aceita as palavras-chaves: FORWARD_ONLY e SCROLL.

03. Usado para definir o tipo do cursor a ser criado: STATIC, KEYSET, DYNAMIC e FAST_FORWARD.

04. Indica o tipo de bloqueio, se as linhas poderão ser atualizadas pelo cursor e, se assim for, se outros usuários também poderão atualizá-los.

05. Este parâmetro instrui o SQL Server para enviar uma mensagem de aviso para o cliente se um cursor for convertido do tipo especificado em outro tipo.

06. Específica às linhas a serem incluídas no conjunto do cursor.

07. Este parâmetro é opcional, por padrão os cursores são atualizáveis a não ser que o parâmetro de bloqueio seja READ_ONLY. Neste parâmetro podem-se especificar as linhas que permitem a atualização. Se forem omitidas todas as colunas na instrução serão atualizáveis.

Variáveis de cursor

O T-SQL permite declarar variáveis do tipo CURSOR. A sintaxe DECLARE padrão não cria o cursor, para isso use o SET a variável explicitamente. Este tipo de sintaxe é útil quando desejamos criar variáveis que possam ser atribuídas a diferentes cursores, o que poderá fazer se criar um procedimento genérico que opere em vários conjuntos de resultados.

Abrir um cursor

A declaração de um cursor cria um objeto cursor, mas não cria o conjunto de linhas que serão manipuladas pelo cursor. O conjunto do cursor não será criado até que se abra o cursor.

OPEN [GLOBAL] cursor_ou_variável

Feche um cursor

Após ter terminado de usar um cursor, devemos fechá-lo. A instrução CLOSE libera os recursos usados para manter o conjunto do cursor e também liberta quaisquer bloqueios que tenham sido colocados nas linhas se tiver usado parâmetros como: SCROLLOCKS.

CLOSE [GLOBAL] cursor_ou_variável

Desalocar um cursor

Na seqüência de criação de um cursor o DEALLOCATE é o último comando. Sua sintaxe é parecida com os comandos anteriores:

DEALLOCATE [GLOBAL] cursor_ou_variável

Este comando remove o identificador do cursor e não o cursor ou variável. O cursor não será removido até que os identificadores sejam desalocados ou fiquem  fora do escopo.   Manipulando linhas com um cursor

O T-SQL suporta três comandos diferentes para trabalhar com cursores: FETCH, UPDATE e DELETE.

O comando FETCH recupera uma linha especifica do conjunto do cursor. Em sua forma mais simples, o comando FETCH possuí a seguinte sintaxe:

FETCH cursor_ou_variável

Um comando FETCH simples

Abaixo veremos um cursor criado para retornar o primeiro registro da tabela de cidades.

                                                       Podemos também utilizar o FETCH para armazenar o resultado em uma variável utilizando o FETCH cursor INTO variavél. Veja o exemplo a baixo:
































Além disso, podemos utilizar o FETCH para com uma combinação de palavras chaves, por exemplo:


. FETCH FIRST – retorna a primeira linha da variável.

. FETCH NEXT – retorna a linha seguinte.

. FETCH PRIOR – retorna a linha anterior.

. FETCH RELATIVE n – retorna a linha n.

. FETCH ABSOLUNT n – pode especificar linhas antes da linha atual.

FETCH NEXT com um cursor firehose  
                                                                    Atualizando linhas com um cursor

Desde que o cursor seja atualizável, alterar os valores subjacentes em um conjunto do cursor é bastante simples. Vejamos o exemplo abaixo:  
                                                          Observe que este script irá retornar duas consultas, uma com o valor inicial do cursor e outro é o SELECT depois do UPDATE.

Monitoramento dos cursores

O T-SQL fornece duas variáveis globais e uma função para auxiliar a compreender o que está acontecendo com os cursores, @@CURSOR_ROWS que retorna o número de linhas no cursor aberto por último pela conexão, abaixo veremos uma tabela com os valores que podem ser retornados pela @@CURSOR_ROWS.   -m O cursor ainda não foi completamente preenchido.

-1 O cursor é dinâmico e o número de linhas pode variar.

0 Ou nenhum cursor foi aberto ou o mais recente não foi fechado e liberado ou o cursor contem 0 linhas.

N O número de linhas no cursor.

@@FETCH_STATUS retorna informações sobre o último comando FETCH que foi lançado, a tabela baixo mostra os valores de retorno para @@FETCH_STATUS.   0 O FETCH foi realizado com sucesso.

-1 O FETCH falhou.

-2 O registro trazido foi perdido.

CURSOR_STATUS é uma função T-SQL que possuí a seguinte sintaxe:

CURSOR_STATUS (tipo, cursor_ou_variável)

O tipo pode ser: local, global ou variable. Os resultados da função seguem  na tabela abaixo:

1 Se a função for chamada para um cursor dynamic, o conjunto do cursor possuirá zero, uma ou mais linhas. Se a função for chamada para outro tipo de cursor, ela possuirá ao menos uma linha.


0 Conjunto de cursores está vazio.

-1 O cursor está fechado.

-2 É retornado apenas para as variáveis de cursor. Ou o cursor atribuído à variável especificada está fechado ou nenhum cursor foi atribuído à variável ainda.

-3 O cursor ou variável de cursor especificada não existe.

Bom, por hoje é isso pessoal, espero que tenham gostado e que tenha ajudado alguém.   se ajudou, da uma clicadinha nos anuncios ai...rsrsrs   fui...

terça-feira, 25 de junho de 2013

Usando NOLOCK no SQL SERVER

Fala pessoal,
ando meio ocupado depois da mudança de emprego, então dei uma parada de postar, mas hoje separei um conteudo para publicar...vamos lá.

Para um melhor entendimento de todos e contextualização do uso de NOLOCK dentro do Microsoft SQL Server é interessante passarmos antes por algumas definições.
O LOCK é um mecanismo usado pelo Banco de Dados para bloquear conteudo na tentativa de sincronizar os múltiplos acessos de diversos usuários à mesma informação.
O uso do lock está diretamente ligado ao controle de concorrência. Este controle pode ser classificado como otimista ou pessimista. No caso do SQL Server, ele possui suporte a ambos, no entanto, o pessimista é o padrão.

Controle de Concorrência Otimista (Optimistic Concurrency Control)

No controle de concorrência otimista, o usuário não cria Locks quando faz a leituras dos dados. Desta forma, quando o usuário for atualizar dados, o sistema verifica se outro usuário está alterando os mesmos dados. Caso positivo, um erro será gerado. O controle é chamado de controle otimista porque é principalmente utilizado em ambientes onde a disputa dos dados é baixa e o custo de ocasionais Rollbacks das transações é menor do que o custo de utilizar Locks em comandos de leitura.

Controle de Concorrência Pessimista (Pessimistic Concurrency Control)

No controle de concorrência pessimista, a base de dados cria Locks que impedem usuários modificarem dados que podem afetar outros usuários de algum modo. No momento em que um usuário faz uma ação, o banco de dados cria um Lock para aquele conteúdo, desta forma, outros usuários ficam impedidos de realizarem ações que conflitem com o Lock até que o primeiro usuário acabe sua transação. O controle é chamado de controle pessimista porque é usado principalmente em ambientes onde a disputa dos dados é alta e o custo da proteção dos dados com Locks é menor do que o custo dos Rollbacks das transações se ocorrerem conflitos.
Com a definição do lock e dos controles de concorrência, fica mais fácil o entendimento do recurso NOLOCK do Microsoft SQL Server.

O NOLOCK permite executar consultas ao banco de dados sem bloquear o conteúdo. Com esta breve descrição é importante a reflexão que o recurso do NOLOCK só faz sentido no uso do Controle de Concorrência Pessimista.
Considerando este cenário, vamos nos aprofundar um pouco mais no recurso NOLOCK do Microsoft SQL Server. Ele possui duas características bem importantes:

1. Permite executar uma instrução SQL sem causar bloqueio da tabela que está sendo lida;

2. Permite ler dados não commitados.

A primeira característica é bem interessante, principalmente quando se busca performance e paralelismo. No entanto, a segunda característica precisa ser bem observada para evitar um uso indevido do NOLOCK e causar problemas no sistema. Diante disto, é muito importante que o desenvolvedor saiba exatamente o que está fazendo quando estiver utilizando o NOLOCK.

Vamos entender a sintaxe para utilização deste recurso. Segue abaixo um exemplo:



– Instrução SQL Normal:

SELECT * FROM NOTA_FISCAL ORDER BY CD_NOTA_FISCAL;



– Instrução SQL com NOLOCK:

SELECT * FROM NOTA_FISCAL WITH (NOLOCK) ORDER BY CD_NOTA_FISCAL;



Vamos agora analisar o uso para uma aplicação com as seguintes características:

1. A tabela de Nota Fiscal é modificada apenas com comandos de INSERT ou DELETE. Nunca UPDATE, pois devido ao negócio da aplicação não existe atualização das Notas.

2. Quem modifica esta tabela é apenas um procedimento de importação que roda através de um scheduler e não permite multi-threads do mesmo tipo. Ou seja, não temos nunca 2 importações de notas fiscais rodando em paralelo, elas ficam em fila se por algum motivo existir uma concorrência.

3. Existem diversas consultas e reports que precisam de acesso rápido a esta tabela de Nota Fiscal.

4. Todos os reports possuem horário de geração.



Diante destas características do sistema, o uso de NOLOCK pode ser recomendado e trazer um beneficio bem interessante a performance das consultas e reports relacionados as notas fiscais.



Vamos entender melhor esta conclusão..



Quando NÃO usamos NOLOCK e estamos no controle de concorrência pessimista, precisamos esperar que os outros procedimentos na tabela acabem para que consultas possam ser realizadas. Desta forma, denegrindo a performance de relatórios que estão rodando em paralelo a procedimentos de importação. No entanto, com o uso do NOLOCK em uma aplicação com as características descritas acima, podemos consultar os dados sem a necessidade de esperar que as importações realmente terminem, pois teremos lá o conteúdo de momento.

O report vai marcar a hora que ele foi gerado e como não são feitos UPDATES nas notas, nunca teremos dados inconsistentes. No pior caso, poderíamos ter uma nota que posteriormente ela seria cancelada (deletada), mas isto é algo comum dentro do negocio da aplicação.



O uso do NOLOCK implica em abrir mão da consistência em nome da melhor concorrência e tem suas aplicabilidades. No entanto, é importante sempre entender bem do negocio da aplicação e utilizá-lo com bom senso para que suas desvantagens não te tragam problemas piores que um problema de performance.

espero ter ajudado alguem com mais esse conhecimento....e não esqueçam da clicadinha basica nos anuncios,  para dar uma insentivada ...rsrs



segunda-feira, 18 de março de 2013

Quebrando String C# (Split + Contains)

Hoje vamos ver 2 métodos c# que juntos podem nos quebrar um galhão quando trabalhamos com arquivos texto ou strings, são eles SPLIT e CONTAINS.
o CONTAINS busca em uma string, um carácter ou palavra especifica, por exemplo encontrar um '|' ou ';' dentro de uma string ( isso parece familiar ? rsrs), e retorna TRUE ou FALSE.
e com o comando SPLIT podemos montar um array de string com essas informações.
por exemplo, se o usuário criou uma lista de e-mails separados com ';' precisaríamos separar os e-mails para adicionar um a um em certos métodos.
exemplo de uso da dupla:

string email = "marcio@hotmail.com;marcio@yahoo.com;marcio@ig.com.br";

if (email.Contains(";"))
{
       string[] emails = email.split(';');
    //agora basta fazer um forech no array e executar o que desejar
}

por hoje é só pessoal

espero que tenham gostado, e não esqueçam da clicadinha no anuncio, curtida no face e comentário...rsrsrsrs

abraços

quarta-feira, 27 de fevereiro de 2013

Coleções .Net ( C# ) - Final - HybridDictionary

Hoje vamos finalizar a série coleções com a classe HybridDictionary, se vc não viu os outros posts, não deixe de conferir:

http://programaresimples.blogspot.com.br/2013/02/colecoes-net-c-parte-1-queue.html
http://programaresimples.blogspot.com.br/2013/02/colecoes-net-c-parte-2-stack.html
http://programaresimples.blogspot.com.br/2013/02/colecoes-net-c-parte-3-hashtable.html
http://programaresimples.blogspot.com.br/2013/02/colecoes-net-c-parte-4-sortedlist.html 
http://programaresimples.blogspot.com.br/2013/02/colecoes-net-c-parte-5-listdictionary.html

A classe HybridDictionary está localizada dentro do namespace System.Collections.Specialized e implementa uma coleção de Chave/Valor, assim como a HashTable então qual é a diferença ?
simples, quando precisamos trabalhar com uma coleção grande a melhor escolha é a HashTable, quando vamos trabalhar com uma coleção pequena, usamos a ListDictionary mas quando não sabemos o tamanho da coleção, ai entra em ação a HybridDictionary, pois enquanto a coleção é pequena ela é implementada como a ListDictionary e quando a coleção fica muito grande ela se converte para HashTable.
a utilização é igual a HashTable e ListDictionary, vamos ver o exemplo:

no evento click da nossa tela padrão começamos com o de costume, instanciando a classe e adicionando algumas informações na coleção para testes:


agora percorremos a coleção adicionando os itens na listBox


depois procuramos um item especifico na coleção e mostramos no listBox


por fim, limpamos a coleção


agora é só testar a aplicação e ver o resultado


bom pessoal é isso, espero que tenham gostado dessa série, que tenha servido pra alguém, e vamos ver o que nos aguarda no próximo post.

um abraço a todos e não esqueçam daquela clicadinha maneira nos anuncios..rsrsrs





sexta-feira, 15 de fevereiro de 2013

Coleções .Net ( C# ) - Parte 5 ListDictionary

Continuando nossa série Coleções .Net (se você não acompanhou os posts anteriores:
http://programaresimples.blogspot.com.br/2013/02/colecoes-net-c-parte-1-queue.html
http://programaresimples.blogspot.com.br/2013/02/colecoes-net-c-parte-2-stack.html
http://programaresimples.blogspot.com.br/2013/02/colecoes-net-c-parte-3-hashtable.html
http://programaresimples.blogspot.com.br/2013/02/colecoes-net-c-parte-4-sortedlist.html 
) , hoje vamos conhecer a ListDictionary, essa classe está localizada no namespace System.Collections.Specialized e implementa uma coleção de Chave/Valor, essa classe é semelhante a HashTable, a grande diferença das duas, é que a ListDictionary é otimizada para trabalhar com pequenas coleções.
vamos ao exemplo

começamos com nossa tela padrão de testes:


no click do botão, colocaremos o seguinte código, primeiro instanciamos um objeto da classe ListDictionary e adicionamos itens na coleção:


agora vamos percorrer a lista adicionando os valores na listBox, e colocamos um separador para indicar o fim do processo:


vamos buscar um item na coleção e adicionar na list box, e adicionar mais um separador:


e por fim limpamos a coleção:


execute a aplicação e veja o resultado:


espero que estejam gostando da série e que eu tenha ajudado alguém,  na próxima veremos a classe HybridDictionary.

um abraço a todos.

gostou ? clica em um anuncio ai !! rsrs









segunda-feira, 11 de fevereiro de 2013

Coleções .Net ( C# ) - Parte 4 SortedList

Continuando nossa série coleções .NET, veremos hoj a SortedList, como todas as outras vistas até agora ela também está localizada dentro do namespace System.Collections, e implementa uma coleção de Chave/Valor assim como a HashTable.
O uso dessa classe é bem semelhante a HashTable, a principal diferença é que o array de chaves da SortedList é sempre ordenado, portanto para cada inserção ou exclusão, a classe sincroniza os itens para que permaneçam ordenados.
Como a HashTable, a classe também não aceita chave duplicada e para percorrer pela coleção é necessário utilizar a classe DictionaryEntry, vamos ao exemplo:

começamos com nosso form padrão de testes ( se você não viu, acompanhe a série):
http://programaresimples.blogspot.com.br/2013/02/colecoes-net-c-parte-1-queue.html
http://programaresimples.blogspot.com.br/2013/02/colecoes-net-c-parte-2-stack.html
http://programaresimples.blogspot.com.br/2013/02/colecoes-net-c-parte-3-hashtable.html


no evento click do botão, começaremos nosso código com o de costume, instanciando um objeto da classe e preenchendo com os itens:


agora percorremos a lista preenchendo o listBox com os itens e adicionamos um separador para marcar o fim da lista:

 
buscamos um item qualquer da lista e adicionamos mais um separador:


 e para finalizar limpamos a lista:


execute o projeto e veja o resultado:

Veja que independente da ordem em que os itens foram adicionados, a SortedList organiza pela chave o que facilita a vida em muitas situações.

espero que tenham gostado de mais esse post, na continuação veremos a ListDictionary.

gostou ? então da uma clicadinha em um anuncio..rsrs...e pode deixar mensagens tb =D

um abraço a todos e até mais