Alan

Thanks for the reply. I actually do exactly what you suggest in many
of the areas of my program. All of the point of sale operations use
this method since I can have up to 60 or 70 terminals hitting on the
system at one time and I would not want to suffer transaction
problems. For the most part I use TStringGrids for alot of the data
at POS and then apply the data to the database in using a lot of
stored procedures that allow me to update up to 12 tables in under a
second or 2.

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.

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.

On the second problem I am wanting to get assurances that the OAT does
get turned off when I use hard start transactions and commit
transactions that. If that is true, then the timeout or deadlock
errors would be my responsibility to ensure that this I need to be
wrapping my transactions with the start and commits. Auto commits
will not work for me. However, many of the features that Jason has put
into the IBO I will start to use in future development.

Best Regards

Jack

--- In IBObjects@yahoogroups.com, "Alan McDonald" <alan@...> wrote:
>
> >I have converted my BDE application that is using Firebird 1.5.3 to
> >IBO4.6Bc. The application is running well, with some bugs that are
> >being fixed as I run into them. I seem to occasionally run into a
> >problem with a transaction holding up other transactions, and after
> >the OAT does it's thing it will timeout the blockage and then work can
> >proceed in that area of the program.
>
> >I am interesting to tinkering with the timeouts, to shorten them so
> >that if a transaction is blocked, it will terminate after a shorter
> >period of time.
>
> Jack, just a thought here before we all get carried away with timeout
> properties...
> you're talking about order creation... this involves using some existing
> (commited) data and the insertion of new data.
> I personally use a different model here completely... gather the
existing
> (unchangeable for this operation) data with a read only transaction
(never
> blocks), and use non-data-aware controls for the collection of the
new (to
> be inserted data). When the op wants to complete the order, they hit a
> button,,, a transaction is started, field values are populated, and the
> transacxtion is commited.. all in a split second.
> Is this not possible in your scenarios?
> Alan
>
> >Any comments would be welcome to solve these two issues.
>
> >Thanks In Advance
>
> >Jack Engleman
>