Subject Re: Firebird Issues
Author delphic_viper
Sorry this has taken so long!!!

Firebird version 1.0.2.908

We have not changed anything about the transaction isolation
settings. In a few areas we begin and commit our own transactions
but this is not common. Our TransIsolation is set to ReadCommited.
We've noticed that the BDE admin on the development PCs has the
option of wait on locks. This is not an option on the workstation
pc's or the server. I can run a huge SQL script on my local machine
and then try to access another table and cause a transaction deadlock
error. In the show room they have noticed that this most often
happens when they give away free gemstones and all ~15 operators are
accessing the same inventory record to add to their order at the ame
time. This is the only time there is a definite pattern in the
deadlock errors. I let the DB go for about a week w/o doing a backup
and restore since I was told that the DBSize was not an issue and it
would cap off at about 200MB. Over that week it grew to nearly
400MB. I don't know if this matters or not.
Thank You,
Branden Johnson

--- In firebird-support@yahoogroups.com, "Alan McDonald" <alan@m...>
wrote:
> > The app was written in Delphi, a pascal language. It is an
inventory
> > and sales system. Throughought 8-12 hours time periods they run
live
> > shows, entering new inventory, customers, work orders, and sales
> > orders. These sales orders are updated throughout the show as
> > customers add to their orders and the inventory system is updated
as
> > items are added onto orders. As orders are taken and added to CC
> > payment info is taken and preauths are recorded on the cards.
After
> > the show is complete every order meeting a predetermined sales
> > criteria are turned into invoices, an entirely different table,
> > payments are charged, and the status of the orders and invoices
are
> > updated throughout this procedure. They run about 1,000 orders
per
> > week. Every time an order is added to, or something is changed
(i.e.
> > shipping, contact info, discounts), the order is recalculated and
> > posted to the DB. Slowness seems to occur when the DB size gets
> > above 100MB! The transaction deadlocks happen very
sporradically, on
> > different tables throughout the DB. We use the Borland Database
> > Enigine (BDE). I obviously don't know as muh as I should about
this!!
> >
> > Thank You,
> > Branden Johnson
> >
>
> there's nothing out of the ordinary here. EXCEPT, BDE - we have to
be
> careful here.
> I presume you are using the standard TQuery component set..
> The size of the DB is nothing and I would argue first up that it
has nothing
> to do with any slowing behaviour whatever. The server manages the
space -
> don't worry about it at all.
> You'd better tell us the FB version you are using. Also tell us if
you've
> fiddled the transaction isolation settings in the BDE. Tell us how
you
> generally manage your transactions.
> Alan