interbase transaction

[humanista (mruczus)]

I have been able to notice that interbase select (just reading data)
transation CAN fail (!) if there is writing to the same table at the same
time at another client in multi-user environment. Is that true?

[Craig Stuntz [TeamB]]

Post by humanista (mruczus)
I have been able to notice that interbase select (just reading data)
transation CAN fail (!) if there is writing to the same table at the
same time at another client in multi-user environment. Is that true?

Depends on the transaction isolation. It's possible (though not
recommended) to lock a table in IB.

When using recommended best practices, it's not possible for a writer
to block a reader.

[Bill Todd [TeamB]]

Post by humanista (mruczus)
I have been able to notice that interbase select (just reading data)
transation CAN fail (!) if there is writing to the same table at the
same time at another client in multi-user environment. Is that true?

It is possible but you really have to work at it. Normally, in IB,
writers never block readers. What transaction settings were you using
for the read transaction?

[humanista (mruczus)]

Post by Bill Todd [TeamB]

Post by humanista (mruczus)
I have been able to notice that interbase select (just reading data)
transation CAN fail (!) if there is writing to the same table at the
same time at another client in multi-user environment. Is that true?

It is possible but you really have to work at it. Normally, in IB,
writers never block readers. What transaction settings were you using
for the read transaction?
--
Bill Todd (TeamB)

TD.IsolationLevel := xilREADCOMMITTED;

If reading can fail with concurrent writing I am going to have to change the
source code and put transaction in a loop with time delay after each try, so
the transaction always be successful.

[Craig Stuntz [TeamB]]

Post by humanista (mruczus)
If reading can fail with concurrent writing

Again, not unless the writer explicitly locks the table.

[Bill Todd [TeamB]]

We need a lot more information to understand the problem.

What version of InterBase are you using. I assume IB2007 since you did
not say otherwise.

What version of Delphi are you using? I assume 2007 since you did not
say otherwise.

Are both the read and write transactions using read committed
transaction isolation?

I assume you are using the dbExpress components for both the read and
write transactions.

Anything else you can tell us about your environment might be helpful.

[humanista (mruczus)]

Post by Bill Todd [TeamB]
We need a lot more information to understand the problem.
What version of InterBase are you using. I assume IB2007 since you did
not say otherwise.
What version of Delphi are you using? I assume 2007 since you did not
say otherwise.
Are both the read and write transactions using read committed
transaction isolation?
I assume you are using the dbExpress components for both the read and
write transactions.
Anything else you can tell us about your environment might be helpful.
--
Bill Todd (TeamB)

So far I have not been able to reproduce the error. It's happened twice with
three users connected at the same time, but I do not know a simple way to
simulate a concurrent access to test the application. I did not see the
error message as it has been wrapped with my custom message. This is a
multiuser environment three-tier thin client with delphi7, interbase 6 (open
source). I use intraweb 5 for clients front-end and dbExpress components for
both the read and write transactions. All transactions use read committed
transaction isolation.

[Bill Todd [TeamB]]

My best suggestion is to modify your custom message display routine to
include the actual error message. Without that it is very difficult to
guess what might be happening.