Hi Michael!

At 09:25 13.01.2003 +0000, you wrote:

>First I assummed, that I had created to many index' on to many tables.
>So laft week i drop a lot of index' on the DB.
>Now every table contains no more than 8 index'.
>Most of the tables only contains 4 index'
>
>Those 4 are always created as 2 asc and 2 desc (on two different
>fields).

The number of indexes is not all too important, what matters is their
selectivity. Just make sure you do not create indexes on fields for which
many records hold the same values.

>1 clients is about to do an update, and therefor starts an
>transaction.
>The connection to the terminal server goes down.
>After a few seconds the session is terminated, by both server and
>client.
>And after another few seconds the firebird DB realizes that the
>connecton has been lost and rollbacks whatever transactions are
>active (Does anyone know how long time there will go) ?

I don't know how long it will take, but I don't think it is very long.

>Until this happens, all other clients that wants to update / insert
>on the same tables must wait (they get a Deadload on no wait
>transaction).

Not quite - all other clients that want to update/delete the same record
must wait. I think you wrote something about updates triggering changes in
other tables. If these other tables are summary tables so that all changes
have to update the same record, then it will appear as if changes to the
entire table will have to wait (if so, you've created a bottleneck). Also,
I think transaction isolation influences how deadlocks are treated.

>So I think that the poor quality of the internet line causes this.
>Is that likely to be the case?

Poor lines may require changes in design I suppose, but it ought to be
possible to overcome.

HTH,

Set

- I support Firebird, I am a FirebirdSQL Foundation member.
- Join today at http://www.firebirdsql.org/ff/foundation