At 05:40 PM 25-07-02 +0000, you wrote:

>Hello
>
>Recently started with IB and still on the learning curve. Using IBO4
>with
>BCB5. What objects should I use in this situation:
>
>I display some contact details (1 row ) to a user who may change the
>details, or they may view the details all day without making any
>changes.
>
>My initial thoughts were to use a TIB_Query linked to some of the IB
>data
>aware components so that if the user changed any details, the Query
>could
>also update the details in the database. But this means the
>transaction
>could possibly be running all day. (doesn't it?)
>
>I have currently using a TIB_Query, to retrieve the details and I
>display
>them in normal TEdit controls etc. When the user finally quits the
>dialog,
>I use a TIB_DSQL object to update the row in the database.
>
>The above works fine, but I get the feeling I'm missing something,
>that this
>could be done more efficiently.

Your idea of picking up the data and displaying them in non-data-aware
controls is one way to go about separating your data from a transaction
context. If you are going to be doing this one row at a time, a
parameterised TIB_Cursor is a more efficient way to get these data, since
you don't need the overhead of a scrollable cursor. Just
start a dedicated transaction
prepare the cursor
pass the parameters
call First and test for EOF (if True, there are no data)
if not EOF read the data into the controls
close the cursor
commit the transaction (commit is cheaper than rollback)

The big drawback to this approach is that your application has no way to
know when the data in this row get changed by another user. You could
implement some kind of hedging structure in your table to mark rows as "in
use", which would have to be updated by the user at start and finish. It's
not just messy and accident-prone, it's contrary to client/server
principles. The purpose of using a RDBMS that can manage concurrency is -
well - to provide concurrency handling.

A more client/serverish alternative would be to include logic so that, when
the user hits the Edit button, a forced refresh of your edit controls is
done and the transaction is kept open until either your update SQL routine
posts changes or the user cancels the edit. Although this defeats the
automation that IBO provides, it's an example of how you can utilise IBO's
"logical transaction" concept and separate the user's "run-time
requirements" from a physical transaction that might or might not
occur. It's one of the main big differences between IBO and all of the
other connectivity solutions.

Really, an important part of the learning curve with IBO is your learning
curve with concurrency and transaction management. Where the BDE was a
"paint-by-numbers kit", IBO is a roll of canvas, a bottle of size, several
hundred tubes of paint and a set of broad and fine brushes. If you know
what you want to paint, you can paint anything.

Sorry this was more didactic than a solution to your business problem. If
there was a quick way to learn how to do client/server programming, I'd
write an FAQ for it...


All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________