Fórum Problemas com transação, IBX e DBExpress, existe solução? #328400

vamos por partes:



sim , isto se deve a parametrização realizada pelo datasetProvider..
O que se ganha com isto????
R: melhora a performace , porque a instrução sql gerada é otimizada.
Podemos tb parametrizar a clausula WHERE , configurando atraves da propriedade providerFlags dos objetos Tfileds
Novamente se ganha em performace com a comunicaçao com o banco

Olá Marco, sim, o DBExpress faz isso por causa do DSP... mas a questão é sobre o lock do registro.. tipo, como nao deixar um usuario modificar um registro que outro está modificando, travar o registro é a solução? e se for um cadastro de clientes enorme, travo, e ninguem mais tem acesso?

Pergunto isso, porque como isso é feito em grandes empresas, tipo RM e Microsiga, que tem mais 100 usuários concorrentes e tals.. como impedir que duas pessoas alterem o mesmo registro!?


[]s

isto novamente e resolvida pelo midas dependendo da configuração dos ProviderFlgas

Um exemplo com dados fictícios foi bem apresentado pelo amigo Vinicius.2k em outro tópico.

Situação 1:

ProviderFlags de todos os TFields = [pfInUpdate, pfInWhere]. Ou seja: Todos os campos estarão aptos a estar presentes na cláusula WHERE.

UpdateMode do TDataSetProvider = upWhereAll. Ou seja: Todos os TFields marcados com pfInWhere estarão na cláusula WHERE.




[b:9e936778d9]Usuários A e B trazem o registro para alteração. [/b:9e936778d9]

Usuário A altera o nome para Marco e aplica os updates.

A Midas resolve para a seguinte instrução:



Observe que a instrução resolvida pela Midas levará em conta o valor que o campo NOME possuia no momento que foi trazido para o lado do cliente, no caso, Vinicius. Se houver correspondência total do registro na tabela com a cláusula WHERE os updates serão aplicados. No nosso caso, tudo certo. A alteração foi salva.

Usuário B altera o NOME para Martins e aplica os updates.

A Midas resolve para a seguinte instrução:



[b:9e936778d9]Os updates não serão aplicados pois não haverá correspodência total no WHERE.[/b:9e936778d9] O valor atual presente no campo NOME deste registro é Marco, fruto da alteração realizada pelo usuário A, porém no momento que ele foi trazido pelo usuário B o valor do campo NOME era Vinicius.
[b:9e936778d9]Qualquer alteração no registro pelo usuário A iria impedir que o os updates do usuário B fossem aplicados porque todos os valores são considerados no WHERE.[/b:9e936778d9] Neste a caso a alteração feita pelo usuário A prevalece.


Situação 2:



[b:9e936778d9]UpdateMode do TDataSetProvider = upWhereKeyOnly[/b:9e936778d9]. Ou seja: Apenas os TFields marcados com pfInWhere e pfInKey estarão na cláusula Where. No nosso caso, apenas ID.

* Devido ao UpdateMode do TDataSetProvider, não faz diferença os TFields restantes estarem ou não aptos a estar presentes no WHERE, já que upWhereKeyOnly estabeleceu que apenas os marcados com pfInKey estariam presentes no WHERE.

Registro:



[b:9e936778d9]Usuários A e B trazem o registro para alteração. [/b:9e936778d9]

Usuário A altera o nome para Marco e aplica os updates.

A Midas resolve para a seguinte instrução:



[b:9e936778d9]Apenas a ID é considerada no WHERE e, no nosso caso, os updates são aplicados com sucesso. A alteração foi salva. [/b:9e936778d9]

[b:9e936778d9]Usuário B altera o campo NOME para Martins e aplica os updates. [/b:9e936778d9]
A Midas resolve para a seguinte instrução:



[b:9e936778d9]Os updates serão aplicados pois, mesmo que o usuário A já tenha alterado o campo NOME para Marco, apenas o valor de ID é analisado e este não foi alterado[/b:9e936778d9]. Neste caso, a alteração do usuário B, sobrepõe a do usuário A.

Acho que este exemplo bem postado pelo Vinicius.2k é um bom começo para tentar entender..

A titulo de curiosidade voce pode colocar um SqlMonitor no projeto , configura-lo para um editor de log e observar as istruçoes sql trocadas com o banco

Infelismente falei so do DbExpress , porque o pouco que eu sei e sobre esta tecnologia.
Fico te devendo Ibx , mas se voce o conheçe , talvez não seje dificil aplicar uma analogia , analizando o ´SqlMonitor´ Dessa Categoria

Espero ter ajudado. :lol:

Olá Marco,

Realmente, para DBExpress você conseguiu uma solução muito boa... vou começar a usar ela...

Porem... a maioria dos sistemas estão em IBX... e precisaria de um solução em IBX...



Agora, estive pensando.. mesmo a sua solução, resolveria o problema da atualização.. mas nao um outro problema... vamos supor que no cadastro de cliente tenha lá seus 50 campos pra alterar... e o usuario começa a alterar e tals.. pra depois clicar no salvar, e ver que nao foi salvo pois alguem mudou antees dele... (como voce explicou acima).

Pois bem, trabalho perdido... queria saber tambem se teria como avisar ao cliente antes de iniciar uma alteracao, se o registro está apto ou nao pra iniciar a edição.. pois assim, o usuario nao perderia muito tempo...


[]s

eu não posso deixar de tirar os meritos da boa explicaçao ao vinicius.2k



os meus não :lol: :lol: :lol:



não entendi... como assim não sera salvo... Na situação 2) não é salvo sem problemas :?: :?: .... O unico campo que não se pode alterar é o campo Chave...este niinguem altera mesmo... Voce não entendeu esta passagem da situação 2 :?: :?: :?:

Olá Marco, realmente, vi la´... o DBExdpress não teria problema, pois o DSP alteraria ]somente o campo que foi modificado.. já no IBX não...

Já que no IBX não há como fazer como no DBX, queria ver se tinha como eu bloquear o cara pra ele nao editar o registro..

Ou....

Uma solução fácil de migração entre IBX e DBX... você conhece algo a respeito?


[]s

se for estritamente necessario , use um Travamento Otimista para o caso



não conheço nenhuma ferramenta que possa ajuda-lo nesse sentido..

vixi.. como eu utilizo esse travamento?


[]s

eu me expressi mau.. Travamento que eu me referi é a estrategia Otimista , que voce ja deve conhecer e que não se aplica ao seu caso...

[b:488f92bd92]quanto a sua afirmação:[/b:488f92bd92]




estive dando uma olhada e cheguei a algumas conclusões que podes estar erradas devido ao meu completo desconhecimento desta classe..

1)
Na paleta de componentes do IBX verifiquei a existencia do componente [b:488f92bd92]IBUpdateSQL ... [/b:488f92bd92]

Por analogia no DBE , ao usarmos o componente[b:488f92bd92] UpdateSQL [/b:488f92bd92], tiramos da sua clausula [b:488f92bd92]where[/b:488f92bd92] todos os campos que não interressam na atualização <situação analoga ao caso 2 do Dbexpress>


então , pergunto a quem interresa por , não existe a mesma opção no
IBUpdateSQL ao escrevermos os paramentros da sua propriedade
ModifySql ????..

2)
eu vi tb que o IbTable possui a opção [b:488f92bd92]UpdateMode[/b:488f92bd92] .. Esta sim pode ser configurada


então vejo muita semelhança com o modelo explicado para o DBEXPRESS
e acredito sim , em uma saida , basta saber a configuração correta.

bom dia amigo titanius

estou precisando de um pequeno favor seu:

Vi em outro tópico que voce usa DBS 2006 ...

Pois bem , fiz o download da versão Win32 e net da Borland

Mas estou tentando estudar UML , togther , refactring e não estou conseguindo.

Não sei se estou sem saber ou se o delhi free não tem essas ferramentas completas

Então gostaria de olhar o IDE do delphi 2006 versão paga , para compara-lo com o meu Free

Claro que se for possivel ....

abraços

:cry: :cry: :cry: era para mandar uma MP para o cara . Olhe so o que eu fiz :oops: :oops: :oops:

e hoje nen é sexta feira ....