USUÁRIO:      SENHA:        SALVAR LOGIN ?    Adicione o VBWEB na sua lista de favoritos   Fale conosco 

 

  Dicas

  Visual Basic    (Banco de Dados)

Título da Dica:  CursorTypes,LockTypes e CursorLocations com VB
Postada em 29/9/2003 por ~Ð@®£@Ñ            
O que são Cursores?
No ADO, quando nós falamos em cursores, estamos falamos sobre uma linha.
Quando você executa uma consulta que retorna vários registros, por exemplo SELECT * FROM Tabela, o resultado usa um cursor para navegar nos registros. O cursor pode ser usado no cliente com o argumento AdUseCliente, ou no servidor com o argumento AdUseServer.Os 4 tipos de cursores são:
AdOpenForwardOnly
AdOpenStatic
AdOpenDynamic
AdOpenKeyset.

Cursor Local (CursorLocation)
O objeto ADODB.Connection (O objeto ADO usado para as trocas de dados entre a aplicação VB e o MySQL Server) tem uma propriedade chamada CursorLocation que é usada para enviar/receber a posição do cursor que será usado por qualquer objeto RecordSet que acessará seus dados através do objeto Connection. As duas opções possíveis para essa propriedade são AdUseServer (padrão) e AdUseCliente .


AdUseServer
Quando você usa o AdUseServer, a responsabilidade para manipulação dos dados gerados pela consulta fica com o banco de dados no servidor. O próprio MySQL não suporta cursores no servidor, então o manipulador dos dados é o Driver ODBC.
O benefício do cursor no lado do servidor é que nós ganhamos acesso ao tipo de cursor dinâmico. Isso permite que nós vemos qualquer as mudanças nos dados que são feitas por outros usuários nos dados que sua aplicação está acessando.

Por exemplo: vamos dizer que você esteja vendendo bilhetes para um concerto com sua aplicação, você precisa saber qual assento está disponível para venda no tempo real para que não seja vendido duas vezes.
Com o cursor no lado do servidor, você tem certeza que os dados que está sendo manipulado é o mais atual. Além que você tem a possibilidade de travar os dados que você está trabalhando quando é editado, para certificar que as mudanças ser gravadas com sucesso no banco de dados.

Com o cursor no lado do servidor (AdUseServer), nós temos acesso aos cursores AdOpenDynamic e AdOpenForwardOnly, e todos os quatro tipos de travamento do RecordSet, que será discutido ao longo do artigo.
Deve-se observar que usando um cursor no lado do cliente, e o cursor AdOpenDynamic em particular, resultará em perda significativa do desempenho, e deve ser evitado quando possível. Além disso, certas funcionalidades, como a propriedade RecordCount do Recordset e as funções GetChunk e AppendChunk para manipulação de campos BLOB, falhará ou retornará resultados anormais quando é usado o cursor no lado do servidor.


AdUseClient
Cursores no lado do cliente, especificado com a palavra-chave AdUseCliente, a manipulação é interna do ADO. Estes cursores oferece mais funcionalidade do que o cursor no lado do servidor e resulta em menos carga ocupada no servidor. A maioria da funcionalidade avançada do ADO é projetado para uso com o cursor no cliente.
E eu pessoalmente uso o cursor do cliente para minhas aplicações (com algumas exceções).
Quando é usado o cursor do cliente (AdUseClient), apenas o cursor AdOpenStatic é disponível, e nós não podemos usar tipo de travamento(LockType) AdLockPessimistic.
O cursor do cliente diminui a carga no servidor do MySQL, desde que com o dado de cursor estático é enviado ao cliente, então o servidor não tem nenhuma comunicação adicional com o cliente. Isso permite que seu servidor escale muito melhor do que com o cursor no lado do servidor.


Tipos de Cursor (CursorTypes)
Além dos dois cursor locais(AdUseServer e AdUseClient), existe quatro tipos de cursor, três são suportados pelo ODBC:
AdOpenStatic (lado do cliente)
AdOpenForwardOnly (lado do servidor)
AdOpenDynamic (lado do servidor)

Os tipos de cursor tem características e funcionalidades diferentes e eu irei discutir isso com mais detalhes. O quarto tipo de cursor, adOpenKeyset, não é suportado pelo MySQL e MyODBC.

AdOpenStatic
O cursor estático é o único cursor disponível quando se usa o adUseClient. Com o cursor estático, o servidor emitirá o resultado ajustado no cliente, depois não haverá nenhuma mais nenhuma comunicação adicional do servidor ao cliente.

O cliente pode comunicar-se devolta com o servidor para enviar as mudanças no servidor. A maioria dos recursos vai para o cliente do que o servidor com o cursor estático, ou seja, o resultado é armazenado na memória do cliente ao invés do servidor.

Se um cliente diferente fizer mudanças nos dados do servidor depois que uma consulta é enviado, o outro cliente não reberá nenhuma notificação das mudanças. O cursor estático é bi-direcional , isso significa que a sua aplicação pode mover o anterior e o próximo registro do RecordSet.

Os seguintes métodos são disponíveis ao RecordSet usando o cursor estático e o tipo de travamento adLockOptmistic (breve mais tipos de travamento)

AddNew
Delete
Find
MoveFirst
MovePrevious
MoveNext
MoveLast
Resync
Update
UpdateBatch
O cursor estático mostrará também um valor exato para a propriedade RecordCount do seu RecordSet, e suporte aos métodos GetChunk e AppendChunk para tratar campos BLOB.

Uma característica do cursor estático é a capacidade buscar dados asynchronously. Quando os dados buscados forem asynchronously, uma linha separada segura a recuperação dos registros, e sua aplicação VB pode retornar registros automaticamente.

Este assunto fica pendente, mas se você quiser testar essa característica, use o adFetchAsync durante a chamada do método RecordSet.Open. Se você especificar qualquer outro tipo de cursor que não seja adOpenStatic usando o adUseClient, será automaticamente convertido para cursor estático.


AdOpenForwardOnly
O adOpenForwardOnly é o tipo de cursor mais rápido de todos, mas tem algumas limitações. O adOpenForwarOnly não suporta a propriedade RecordCount e o método MovePrevious do objeto RecordSet.

A forma mais eficiente de se fazer uma consulta é usando o adOpenForwardOnly com o cursor de travamento adLockReadOnly. Apenas os métodos seguintes do RecordSet são suportados por um cursor adOpenForwardOnly e um travamento Optimistic:

AddNew
Delete
Find
Update
UpdateBatch
Com o MySQL e MyODBC, nós podemos especificar a opção 1048576 na sua string de conexão ou indicar a opção "Don't Cache Results" no gerente de conexão ODBC. Com essa opção, o uso da memória no cliente é limitado e apenas um registro é alocado na memória.

Com cada chamada no método MoveNext do RecordSet, o registro é discartado e o próximo registro é requerido pelo servidor.


AdOpenDynamic
Enquanto o adOpenForwardOnly é o mais rápidos dos tipos de cursores, o cursor dinâmico é o menos eficiente. O cursor dinâmico suporta a ativação manual usando a opção 32 na sua string de conexão, ou marcando a opção "Enable Dynamic Cursor" no gerenciador ODBC.

Sem essa opção, qualquer outro tipo de cursor do que forward-only pode ser convertido automaticamente para cursor estático, com a opção ativada, todos os cursores fora forward-only irá se converter para dinâmico.

Por que o cursor dinâmico é tão lento? Por que não há nenhum suporte nativo para cursor dinâmico, cursor no lado do servidor no MySQL, todas as chamadas para movimentação de registro(MoveNext, MovePrevious, etc.) o driver MyODBC converte seu método para uma consulta SQL, fixa a consulta, e retorna o registro.

Isso significa também que para um cursor dinâmico trabalhar corretamente, você precisará de um campo com chave primária para determinar anterior e próximo. Por isso, os cursores dinâmicos não são recomendados a menos que seja muito necessário.

O cursor dinâmico suporta os seguintes métodos do RecordSet aberto com cursor de travamento Optimistic:
AddNew
Delete
Find
MoveFirst
MovePrevious
Update
UpdateBatch

O cursor dinâmico pode ser benéfico para aplicações multi-usuários, é melhor evitá-lo quando possível, e trabalhar com aplicações multi-usuários quando possível chamando os métodos resync e requery quando possível, e executando comando UPDATE somando e diminuindo valores usando Count do que usar recordsets para atualizar.


Tipos de Travamento (LockType)
Quando as posições do cursor e os tipos do cursor especificam como nossos dados estão sendo segurados, a propriedade do tipo do travamento especifica como vamos travar os dados para proteger todas as mudanças que você fizer e assegurarmos que foram processados.

Existe quatro tipos de travamento, e o tipo de travamento é indicado no método Open do objeto RecordSet (pode ser também indicado usando a propriedade LockType do objeto RecordSet). Os quatros tipos de travamento são:
adLockReadyOnly (padrão)
adLockOptimistic
adLockPessimistic
adLockBatchOptimistic
Todos os quatros tipos pode ser usado com o cursor no lado do servidor, e o adLockPessimistic não é hablitado para o cursor no lado do cliente.

adLockReadyOnly
O tipo de travamento padrão é AdLockReadyOnly. O travamento de apenas-leitura é o travamento mais eficiente para acessar um dado, porque ele não verifica se o dado mudou na hora da consulta e consequentemente não há nenhum tráfego extra entre o servidor de carregar os registros.

Como o nome implica, usando um travamento apenas-leitura não enxerga qualquer mudança feita na tabela. Se você ver algum erro como "Current recordset does not support updating", entao você precisa mudar seu tipo de travamento para adLockReadyOnly.


adLockOptimistic
O travamento otimista é usado para modificações que acontecem simultaneamente, ou onde tem múltiplos usuários fazendo mudanças nos mesmos registros. Com um bloqueio opmistic, a tabela ou o registro bloqueado quando o método Update do RecordSet é chamado.

Isso assegurará que a mudança foi feita com sucesso, mas não impede que outros usuários mudem os dados que você mudou pelo VB.

O tipo de bloqueio adLockOptimistic é tipicamente sua melhor escolha ao decidir-se em um bloqueio da tabela para uma situação que não seja de apenas-leitura. Na maioria das aplicações, os dois tipos de bloqueio que eu uso são adLockReadyOnly e adLockOptmistic.


adLockBatchOptimistic
Quando é usado o bloqueio adBatchOptmistic, as mudanças será alocada no cache até que o método UpdateBatch do RecordSet seja chamado. Quando o UpdateBatch é chamado, todas as mudanças serão feitas no servidor em grupo.

Isso pode fazer a inserção de um grande número registros mais eficiente. (Detalhe: chamando um "ALTER TABLE mytable DISABLE KEYS" depois de uma longa pacote de inclusão, seguido por "ALTER TABLE mytable ENABLE KEYS" depois do pacote completo, pode melhorar muito a velocidade do processo de inclusão por pacote, enquanto MySQL pode reconstruir um índice mais rapidamente do que adicionar uma entrada de cada vez.


adLockPessimistic
Em uma situação de simultaniedade elevada, com os vários usuários modificando os mesmos dados, você irá precisar de um tipo de bloqueio pessimistic. Com o adLockPessimistic, os registros (ou a tabela) serão bloqueados assim que você começar a fazer mudanças no registro atual, e não será desbloqueado até que o método uUdate seja chamado.

Isso assegurará que você não tenha mudado um registro junto com outros usuários, especialmente com uma tabela MyISAM, com características de bloqueio somente nível de tabela.

Certifique-se de que as mudanças estão seguindo imediatamente pelo método do Update do Recordset, e que não tenha nenhuma ruptura para o usuário entrar com uma mudança e o update a fim de não assegurar nenhuma longa ruptura (e melhorar os bloqueios cancelados pelo banco de dados) na operação do banco de dados

Evite usar o adLockPessimistc quando possível, porque é muito recurso intensivo e envolve muito mais o trabalho no lado do cliente e do servidor.


Conclusão
Quando tiver um grande número de combinações de CursorType e CursorLocation, os únicos que estão disponível para o programador VB/MySQL são:
adUseClient - adOpenStatic
adUseServer - adOpenForwardOnly
adUseServer - adOpenDynamic

Para maioria dos usuários, adUseClient com adOpenStatic é a melhor escolha, com o bloqueio adLockReadyOnly para qualquer operação de somente leitura (exportar para um arquivo, carregar registros em um ListView, ComboBox, etc.) e adLockOptmistic para qualquer operação de leitura/gravação.

adOpenDynamic e adLockPessimistic é a melhor solução para situações onde você precisa assegurar que vários usuários não corrompe cada outros dados.

A combinação do adUseServer, adOpenForwardOnly e adLockReadyOnly oferece a melhor performance para operações de preechimento de controles e exportação de arquivos.

Quando combinado com a opção 1048576 (Don't cache query results), adOpenForwardOnly fornece também uma excelente performance de memória, já que apenas um registro é carregado na memória.

Artigo traduzido por João Carlos C. Silva
Artigo original escrito por Mike Hillyer (http://www.vbmysql.com)
 


CyberWEB Network Ltda.    © Copyright 2000-2024   -   Todos os direitos reservados.
Powered by HostingZone - A melhor hospedagem para seu site
Topo da página