Hello,

In a form with data-aware controls (like TDBGrid) usuallay there
are post- and cancel-butttons (like on a TDBNavigator).

But I don't like these standard Dataset-Actions,
since the records are posted anyway, when the user changes the
record. This gives the user little control.

Instead I would rather use Transactions. I start a transaction at
Application-Startup. On the Post-Button I call Commit,
and on the Cancel-Button Rollback. Immediately after this
I start a new transaction.

Is it a good practise ? I ask here, because I never saw this in an
application.
Is there any issue because the transaction could be open for a relatively
long time.

Greets Luzi

Luzi Calivers wrote:


> Is it a good practise ? I ask here, because I never saw this in an
> application.  Is there any issue because the transaction could be
> open for a relatively long time.
>

Kia Orana Luzi

Answering based on DBISAM knowledge, not EDB.  

It sounds like a bad idea.  Throughout your transaction, there will be
locks placed on the tables.  In DBISAM this would prevent other users
updating the tables - presumably there must be someting similar in EDB.
Effectively you'd have a single user application in which each took a
turn in using.  Coffee breaks would be a disaster!!

Maybe you could use the BeforeScroll event to control this - test to
see if your table is in insert or edit mode and if so cancel the scroll.

Cheers

Jeff

--
Jeff Cook
Aspect Systems Ltd
www.aspect.co.nz
+
Joan and Jeff Cook
The Cooks Oasis
www.cookislandsoasis.com

Luzi,

<< Is it a good practise ? >>

No.  Transactions must always be kept as short as possible due to the
locking used:

http://www.elevatesoft.com/manual?action=mantopic&id=edb2sql&category=0&topic=12

--
Tim Young
Elevate Software
www.elevatesoft.com

Jeff Cook wrote
> Kia Orana Luzi

I guess this means hello

Thanks Jeff for your answer. I knew there was something bad about my idea


Maybe cached updates is for this purpose. Is it already implemented ?

Greets Luzi

Thanks Tim

I think cached updates would be for this purpose, but not yet
implemented as per the documentation.

Luzi Calivers wrote:

>
> Jeff Cook wrote
> > Kia Orana Luzi
>
> I guess this means hello

Yes, it is a general purpose greeting in the Cook Islands language.
Literally it means "Be healhty!
>
> Maybe cached updates is for this purpose. Is it already implemented ?
>

Never used them in DBISAM and yet to use EDB - so not really in a
position to answer.

Kia Manuia  ("Be lucky!)

Jeff

--
Jeff Cook
Aspect Systems Ltd
www.aspect.co.nz
+
Joan and Jeff Cook
The Cooks Oasis
www.cookislandsoasis.com

Dear Luzi,

> I think cached updates would be for this purpose, but not yet
> implemented as per the documentation.

Unofficially available in the latest build of EDB. I use them
without problems so far

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Luzi


If you don't like the "scroll = post" idea (and I must say I don't) why not use unbound controls or non-sensitive sql result sets?

Roy Lambert

Luzi,

<< I think cached updates would be for this purpose, but not yet implemented
as per the documentation. >>

As Michael indicated, yes, they are in EDB now but not documented yet.  The
only requirement is that you have a primary key present on any table that
you want to use cached updates with.  Also, ON ERROR triggers are used for
handling update application issues, not a special event handler in the EDB
components.  The reason for this is that EDB uses the replication core to
actually implement the cached updates, so that the application of the
updates behaves just like loading updates during replication.

Apart from that, the cached updates work just like with DBISAM.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim and Michael,

Thats good news!

Thanks Luzi