Hi Eyal,

>Questions and Problems:
>
>1. Which should I use TIBOTable or TIBOQuery?
>

TIBOTable is something that you should use just if you are converting
from old applications, and until you get rid of it.
IBO has very nice features to allow you to use TIBOTable, and Jason
spend a lot of time improving it, but... just don't. You are working on
a client server environement, the sooner you stop thinking about Tables
the better.

>2. Should I use cached updates? Before posting a deal to the DB I must
>check that the data is valid, eg. that the balance of all detail rows
>is exactly 0, that the same account doesn't show up in two different
>rows, etc.
>
>

This is up to you. You don't need it for this purpose, but maybe you
find some advantages using it.

>3. Should I take control of the transaction? I must avoid, for
>example, a deal with a master row but no detail rows.
>
>

For sure. You want everything to happen in "one go" at the server site.
You will need to start the transaction implicity, and close it the way
you feel it's ok: commiting or rollback.

>4. When I try to input a new detail row I get an error box that
>compains "missing value for MASTER_ID". I guess this is because
>MASTER_ID is defined in the DB as "Not Null". But when entering detail
>rows for a new deal, there isn't yet any master row. So which value
>should go into DETAIL.MASTER_ID?
>
>

The ID of the master. You should post the master first, and get an ID
for it. Remember that this is something inside your transaction, so this
ID (and everything else) will be just visible to you.

>5. There are additional "missing value" messages for other fields.
>Those are calculated fields, which can be calculated only after the
>user inputs all data (ie. user click OK). How can I tell TIBODataset
>to "be patient" with those fields until I actually try to post?
>
>

Just post them. :-)
Once again, remember that you are working inside your transaction. You
can rollback at any time.

>6. I need to maintain sequential row number withing each deal. I want
>this to be automatic without any user intervention. It looks like the
>only way is to maintain that column in the dataset using events
>(AfterInsert, AfterDelete). Is there a better way?
>
>

I think you just need to have this order sequencial after the user
inputs everything . My suggestion will be for you to work in a matter,
that just before commit you create this sequential number.

>7. I want to let the user move detail rows relative to each other.
>Leaving the GUI drag&drop implementation aside, how do I re-order the
>rows in the dataset? For a new deal the rows are not yet in the DB, so
>a re-query with ORDER BY is irrelevant. For editing existing deal, I
>don't want to post/query for every row move, because the user may play
>around with the rows, so it's better to just post once in the end.
>
>

They are in the Database, *but* inside your transaction. Once again, you
don't need to worry because this will not be visible to other users (or
better - to other transactions, even inside your own application).

>I think that's it for now. I guess I'll have more when I try different
>solutions. So far I only dealt with reading queries and mostly it went
>straighforward, even the most complex queries. But now that I have to
>do inserts/edits for a master-detail data, which also has many twists
>and conditions, I feel that I'm losing my way.
>
>

I think you just miss the potential of transactions. Take a few time and
learn about it. See the examples that IBO provides you.

Quoting Helen: "Use the transaction, Eyal, use the transaction"

Artur