> > * In some kind of Save button, start a transaction, loop through the
> > list box items, execute SQL to update the database to reflect their

new

> > status, commit the transaction.
> >
> > This uses no refreshes or any other server access until they click

Save.

From: "Jason Wharton" <jwharton@...>

> This is a slick way to do it as long as there aren't any other things

that

> have to be coordinated in, like triggers and changes in other tables

to

> reflect the current status of things during the transaction. In my

case, I

> needed the server to be part of the user interactions. I agree that

many


Jason,

In the last few years, most of the work I have done has involved
multi-tier architectures (application servers, lots of Java), web
applications, and other backend-centric work. As a result, I have not
even had the option of using the database server as part of
click-by-click user interactions. Prior to that, most of the
client-server applications I build did not use the server heavily in the
manner you describe; I used triggers to do complex integrity checks,
stored procedure to move certain kinds of processing to the server, etc.
I generally posted to the database server when the user had finished a
piece of interaction. For many database servers, this is the strongly
recommended approach; long-running transactions are widely frowned upon
for good reason.

However, I am intrigued by the idea of the database server as an
intimate part of user interaction, since Interbase's design tolerates
open transactions well. I would like to hear some scenarios (or have
you point me to code examples in the IBO install) where this approach is
used, so that I could understand the benefits thereof.

[ Kyle Cordes * kyle@... * www.kylecordes.com ]
[ Developer, Consultant, Trainer: Java, Delphi, ASTA, etc.]
[ Visit the site for articles, links, BDE Alternatives ]
[ Guide, JBuilder Open Tools, and a Delphi Wiki, and more ]