Yes. In a ERP System, with Stock Control. When a user need to updated the
quantity of a item.

Not rarely, when some user need to update the item, another user already
begin update in another computer in the network. If this first transaction
hold the item and delay in release and commited, then the last transaction,
when posting, receive the message of ‘deadlock’.

But if the second transaction knew that the item was being updated in
another transaction, then waited for the release and commit, and conclude
the post, without the risk of ‘dealock messages’.





Thanks

____________________________________

Hércules Russano

<http://www.hrsoft.com.br/> http://www.hrsoft.com.br

HRsoft Informática - Rio de Janeiro - Brasil



De: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com] Em nome de
Geoff Worboys
Enviada em: quinta-feira, 15 de abril de 2010 21:34
Para: IBObjects@yahoogroups.com
Assunto: Re: [IBO] Row edited but not committed - deadlock





Hi Hércules,

> Before post a record: how to know if that record was edited
> but not commited in another transaction, on the network?
> In the IB_Database connection:
> - autocommit=true, isolation=tiCommited, recversion=true, lockwait=false

ie. These are the defaults.

> I'm trying to avoid deadlock!

Are you trying to work around a known/specific problem... or is
"deadlock" something you've read about and decided you should
do something about it?

If you don't have a specific problem then working with the
defaults until you experience a specific problem is usually the
best way to make progress.

However... I cannot say that I am a fan of TIB_Database. It is
OK for small and simple applications that only ever need a
single transaction... but if you have something that may get
more complicated then you will want to start with TIB_Connection
and a separate TIB_Transaction for each conceptual transaction.
(For example it is likely that each form may have it's own
transaction.)

[[ If you are new to transactions spend some time playing with
the various demo and tutorial applications until you gain some
experience and confidence using transactions. Transactions can
be really really useful but setting AutoCommit to true avoids
many of the benefits. Learning about transactions will help
you design more useful applications. See the transaction
tech-info sheets at: http://www.ibobjects.com/TechInfo.html ]]

If you really want to lock a record when it is edited then
you need to look at the PessimisticLocking property of the
query/cursor you are using. Note that for this to be effective
you will probably have to turn off AutoCommit (in your
TIB_Transaction or TIB_Database), which will mean implementing
your own transaction control (usually a good thing anyway).

While there can be situations in which PessimisticLocking is
useful, to use it throughout your application may lead to
more trouble than it solves.

Note also that "DML Caching" is another way to deal with the
issue of updates coming from multiple users.
http://www.ibobjects.com/TechInfo.html#ti_dmlcaching

HTH

--
Geoff Worboys
Telesis Computing



Nenhum vírus encontrado nessa mensagem recebida.
Verificado por AVG - www.avgbrasil.com.br
Versão: 8.5.437 / Banco de dados de vírus: 271.1.1/2813 - Data de
Lançamento: 04/15/10 18:31:00



[Non-text portions of this message have been removed]