>Alan

>My problem is that I have some activities that occur in the
>headquarters and warehouse that can conflict with activities at the
>stores and they are the ones who will suffer the deadlocks at the
>warehouse and not at the stores. In one operation that scans orders
>for current deliveries (it runs about every two hours at the
>warehouse) I can conflict with an order being produced at a store, but
>I simply would jump over that order in the processing and that order
>will picked up on the next run of that function. That worked great on
>the BDE version, but I had conflicts with the coverted code, so I had
>to change the code and quickly to allow my customer to process his
>orders for that week.

Sounds more like your transaction settings are wrong for the warehouse
select operation. These reads should never block and order creation.
I'm not sure Timeouts are your answer anyawy - could be that you're focused
on the wrong thing.
Alan

>I have shorten the timeout, just so that if a deadlock or a lock
>occurs it will be a shorter period of time before the deadlock
>disappears. With the standard settings it took fifteen or twenty
>minutes, before the OAT would release the lock. I have not been
>contacted by any of my clients in the last 4 days concerning
>deadlocks, but there business will increase by six or eight times the
>volume in about two months, so I want to have these problems behind me
>before my clients get into the busy season.