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

--- In firebird-support@yahoogroups.com, "Alan McDonald" <alan@m...>
wrote:

> > I am running Firbird v. 1.0.2.908 on a 2000 server. The company
> > using this is reporting very slow processing and daily "wait on
> > transaction deadlock" errors. Also, over a 48-72 hour time

period,

> > the .gdb file, which is ~80MB, grows to ~160MB. The file size is
> > reduced back to ~80MB after a backup and restore is done. PLEASE
> > HELP !!!!!
>
> hmm yep - think that's enough information to go on.. now lets

see....

>
> The first issue could be anything - you'd beter tell just a litle

more about

> how you are using the database.. app language, typical tasks... etc

etc

> etc... don't stop.
>
> the issue about db size is nothing to fret about. FB has dynamic

sizing. It

> will grow to accommodate inserted data, then if you delete masses

of data,

> it will use this space again when you next insert masses of data

which it

> sounds like what you are doing.
> let it grow to 200Mb and you'll probably see it not grow much more

after

> that.
>
> Alan