Subject | Re: Firebird Issues |
---|---|
Author | delphic_viper |
Post date | 2004-08-12T14:21:06Z |
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:
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 aninventory
> > and sales system. Throughought 8-12 hours time periods they runlive
> > shows, entering new inventory, customers, work orders, and salesas
> > orders. These sales orders are updated throughout the show as
> > customers add to their orders and the inventory system is updated
> > items are added onto orders. As orders are taken and added to CCAfter
> > payment info is taken and preauths are recorded on the cards.
> > the show is complete every order meeting a predetermined salesare
> > criteria are turned into invoices, an entirely different table,
> > payments are charged, and the status of the orders and invoices
> > updated throughout this procedure. They run about 1,000 ordersper
> > week. Every time an order is added to, or something is changed(i.e.
> > shipping, contact info, discounts), the order is recalculated andsporradically, on
> > posted to the DB. Slowness seems to occur when the DB size gets
> > above 100MB! The transaction deadlocks happen very
> > different tables throughout the DB. We use the Borland Databasethis!!
> > Enigine (BDE). I obviously don't know as muh as I should about
> >be
> > Thank You,
> > Branden Johnson
> >
>
> there's nothing out of the ordinary here. EXCEPT, BDE - we have to
> careful here.has nothing
> 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
> to do with any slowing behaviour whatever. The server manages thespace -
> don't worry about it at all.you've
> You'd better tell us the FB version you are using. Also tell us if
> fiddled the transaction isolation settings in the BDE. Tell us howyou
> generally manage your transactions.
> Alan