Subject | Re: Client in FireBird |
---|---|
Author | lysander_fb |
Post date | 2005-06-23T07:48:16Z |
--- In firebird-support@yahoogroups.com, "Gustavo" <gusm@d...> wrote:
dBase/BDE(ODBC)/Firebird.
I also am in the dead-corner that I can not just switch off the
temptable-approach. As a matter of fact, BDE/dBase was only sufficient
fast in the network WITH temptables.
Where I am still needing temptables I am doing the following, and it
works good:
create an additional database, for example "Temptables.fdb"
For every table that you plan to use as a temptable, add a
"session-id"-field to the structure.
session-id can be an autoinc by use of a generator (this is how I am
doing it), but I guess that using Current_Transaction or a selfmade
key of "date/time/user" would also be good.
create one session header
in the header, for every new session, insert a record
(session-id, tablename, state-of-process, maybe additionally starting
and ending datetime of the session).
starting the session has a process-state of 1
finishing it is 2
aborting it is 0
In a house-cleaning module I am deleting from my temp-database all
records where the session state is 0 or 2, and I am reviewing all
sessions which have a state of 1 but are already running for more than
one day.
Using this approach, I can use Firebird instead of dBase, but can
afford to change the data-access-components only step by step.
~~~
There is no perfect guide for when to use commit() or
commitretaining(). As a rule of thumb, if you do not EXPECT a lot of
failed transactions, and therefore don´t have a need for frequent
rollback()s, better use commit().
ciao,
André
application, copies the registers of the temporary table to the not
temporary employee table.
> Adam (and David):I am also converting dBase/BDE/dBase to Delphi/Firebird, via
dBase/BDE(ODBC)/Firebird.
I also am in the dead-corner that I can not just switch off the
temptable-approach. As a matter of fact, BDE/dBase was only sufficient
fast in the network WITH temptables.
Where I am still needing temptables I am doing the following, and it
works good:
create an additional database, for example "Temptables.fdb"
For every table that you plan to use as a temptable, add a
"session-id"-field to the structure.
session-id can be an autoinc by use of a generator (this is how I am
doing it), but I guess that using Current_Transaction or a selfmade
key of "date/time/user" would also be good.
create one session header
in the header, for every new session, insert a record
(session-id, tablename, state-of-process, maybe additionally starting
and ending datetime of the session).
starting the session has a process-state of 1
finishing it is 2
aborting it is 0
In a house-cleaning module I am deleting from my temp-database all
records where the session state is 0 or 2, and I am reviewing all
sessions which have a state of 1 but are already running for more than
one day.
Using this approach, I can use Firebird instead of dBase, but can
afford to change the data-access-components only step by step.
~~~
There is no perfect guide for when to use commit() or
commitretaining(). As a rule of thumb, if you do not EXPECT a lot of
failed transactions, and therefore don´t have a need for frequent
rollback()s, better use commit().
ciao,
André
> registers. The DataSource.DataSet property of this grid is thetemporary table. When the user clicks the "save" button, the
application, copies the registers of the temporary table to the not
temporary employee table.
>better performance than using CommitRetaining.
> I believe I remember reading in this forum that using Commit has