| Subject | Re: [firebird-support] Re: Resolving Lock conflicts on the Firebird server |
|---|---|
| Author | David Johnson |
| Post date | 2006-03-09T13:20:12Z |
On Thu, 2006-03-09 at 08:47 +0000, colincoleman2002 wrote:
The TClientDataset, for practical purposes, may be considered to be an
in-memory ISAM (paradox or dBase) table. Data aware controls may run
against TClientDatasets. If someone has a "TMemoryTable" or something
similar and you don't want to use Borland's component, that would
probably work too.
Query results are loaded into a TClientDataset (or other in-memory
tabular representation of a query result), where they are edited in-
memory. On completion, the TClientDataset (or other in-memory
structure) is traversed and only the changes are written back to the
database.
We found the IProvider interface too clunky for real use. So we run in
briefcase mode and have our own code to traverse the deltas.
Under no circumstances does the user's form ever interact directly with
the backing database. Database transactions are always batched behind
the "select" and "save" buttons, or within a worker thread that starts
and ends a transaction cleanly.
A third approach to this is to load arrays of record structures, use
standard (non-data-aware) controls, and track the changes yourself. We
have a couple of apps that do that. It is not too painful, but the
rework involved in your app would probably make it unpalatable.
business better than I do, so you will understand where to make the
break better than I. Where we have large amounts of static data that is
heavily used, we do cache that locally.
Under no circumstances does the user's form ever, ever, ever tie
directly to the backing database. The form ties to the in-memory
structure. The code behind the "Save" button traverses the in-memory
data and applies the updates. The code behind the "Ok" button on your
search screen selects only the requested data and populates the in-
memory structures.
Between runs, each in-memory dataset may be cleared or left populated as
required for best accuracy and performance.
If you use the TClientDataset, the biggest changes to your code will be
what your form is tied to, and that you run your queries as one-shot
batch processes off of the appropriate form events.
The form controls should never actually connect to the backing database?
They were intended for work in ISAM systems (BDE) and tend to choke
RDBMS systems. The use of an ISAM like middle layer in memory insulates
the RDBMS from the evils of ISAM-like processes. Just because someone
added a state to Firebird to support ISAM-like transactioning does not
make it a good thing.
> Thanks David,No ... there is generally no local database, as such.
>
> 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?
>
The TClientDataset, for practical purposes, may be considered to be an
in-memory ISAM (paradox or dBase) table. Data aware controls may run
against TClientDatasets. If someone has a "TMemoryTable" or something
similar and you don't want to use Borland's component, that would
probably work too.
Query results are loaded into a TClientDataset (or other in-memory
tabular representation of a query result), where they are edited in-
memory. On completion, the TClientDataset (or other in-memory
structure) is traversed and only the changes are written back to the
database.
We found the IProvider interface too clunky for real use. So we run in
briefcase mode and have our own code to traverse the deltas.
Under no circumstances does the user's form ever interact directly with
the backing database. Database transactions are always batched behind
the "select" and "save" buttons, or within a worker thread that starts
and ends a transaction cleanly.
A third approach to this is to load arrays of record structures, use
standard (non-data-aware) controls, and track the changes yourself. We
have a couple of apps that do that. It is not too painful, but the
rework involved in your app would probably make it unpalatable.
> I can see the immediate advantage of only contacting the main dbYou only download the information as they need it. You know your
> 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?
business better than I do, so you will understand where to make the
break better than I. Where we have large amounts of static data that is
heavily used, we do cache that locally.
Under no circumstances does the user's form ever, ever, ever tie
directly to the backing database. The form ties to the in-memory
structure. The code behind the "Save" button traverses the in-memory
data and applies the updates. The code behind the "Ok" button on your
search screen selects only the requested data and populates the in-
memory structures.
Between runs, each in-memory dataset may be cleared or left populated as
required for best accuracy and performance.
If you use the TClientDataset, the biggest changes to your code will be
what your form is tied to, and that you run your queries as one-shot
batch processes off of the appropriate form events.
The form controls should never actually connect to the backing database?
They were intended for work in ISAM systems (BDE) and tend to choke
RDBMS systems. The use of an ISAM like middle layer in memory insulates
the RDBMS from the evils of ISAM-like processes. Just because someone
added a state to Firebird to support ISAM-like transactioning does not
make it a good thing.
>My bad.
> 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 ;-)
>
> CheersI hope this helps.
>
> Col
>