Thanks David,

I am very interested in any other way to get around this problem,
the system is getting large width wise (number of tables), where one
delphi form using IBO 4.x has 218 Tdataset controls on it, a load of
them are DBlookupcombos, due to the fact the system is creating a
recipe for mixing multi layered polythene film, the users love the
delphi system because the old system worked on 1 layer ata time, and
to create a recipe they were going in and out of forms that took
about 20 seconds to create, so the new system works well, but id
like to know if your method, copies all the lookup tables values
into a local firebird Db on each client desk, then runs the form
against the virtual Db, then when it comes to posting asks the main
DB for the next generator keys for each table and then loads each
table across the void by hand?

I can see the immediate advantage of only contacting the main db
during the transfer, but then when they need to lookup all the
orders and recipies for each customer they would either have to
download a few gig to each client to do the lookup or, may we could
split the system so that it only does this virtual DB mode when
editing or creating new records, is this correct?

Oh and Helen if your reading this, i did take it in the spirit in
which they were delivered. I was always told the way to train a dog
is to give a it a good slap,........guess i had one then ;-)

Cheers

Col




--- In firebird-support@yahoogroups.com, David Johnson
<johnson_d@...> wrote:

>
> Having read the entire thread now, including your comments to Helen
> (which are undeserved IMHO), I have a more concrete suggestion.
>
> Scalable apps uses a "pseudo-conversational" model when talking to

the

> backing database. That is, you retrieve the data into a local

store

> (TClientDataSet, for example) and commit, perform your work

locally,

> then apply changes and commit in a separate transaction later.
>
> At no point in time is a lock held.
>
> I have delphi apps sharing a mission-critical real time database

that

> processes well over a million transactions per hour with 8,000
> concurrent users and an indeterminate number of real-time automated
> processes.
>
> The model is reliable - my last Delphi app,supporting roughly
> $300,000,000 per year in business, has gone for three years now

without

> any support. The team that "owns" it now had to get my help to
> recompile it because it had been so long since it was touched and

they

> don't have any Delphi skills on that team.
>
> This is also the model used by all CICS and web development, so it

is

> not a new or novel concept.
>
> I hope this helps.
>
>
> On Tue, 2006-03-07 at 11:12 +0000, colincoleman2002 wrote:
> > Every now and then our Delphi 7 app, running against a FB 1.5.x
> > server
> > decides to throw a lock conflict at the users, up till now the
> > solution has been for all the users to log out one by one untill

the

> > lock is released and then they can all carry on again, bit of a

pain

> > when 70 users plus are logged in.
> >
> > Is there a way of asking the server what lock conflicts are

active

> > and
> > which connections caused them?
> >
> > would make my life very easy then to tell the locking connection

to

> > save / abort.
> >
> > Thanks
> > Colin
> >
> >
> >
> >
> >
> >
> >

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

> >
> > Visit http://firebird.sourceforge.net and click the Resources

item

> > on the main (top) menu. Try Knowledgebase and FAQ links !
> >
> > Also search the knowledgebases at http://www.ibphoenix.com
> >
> >

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

> >
> >
> >
> >
> > SPONSORED LINKS
> > Technical support
> > Computer technical
> > support
> > Compaq computer
> > technical support
> > Compaq technical
> > support
> > Hewlett packard
> > technical support
> > Microsoft technical
> > support
> >
> >
> >

_____________________________________________________________________
_

> > YAHOO! GROUPS LINKS
> >
> > 1. Visit your group "firebird-support" on the web.
> >
> > 2. To unsubscribe from this group, send an email to:
> > firebird-support-unsubscribe@yahoogroups.com
> >
> > 3. Your use of Yahoo! Groups is subject to the Yahoo!

Terms of

> > Service.
> >
> >
> >

_____________________________________________________________________
_

> >
>