> from Delphi's TQuery. That's the help you should look at -- albeit
> Borland's helpfile on this issue is minimal.

Borland's help isn't only minimal but also badly written in general.
It usually explains what, but not how and why.

> just gonna have to *believe* it when I tell you that the detail's
> Datasource property provides the set-to-set datalinking for a
> TQuery/TIBOQuery detail/master relationship.

Ok, I believe :-)

> Do you actually understand that Post writes to the database? Fb/IB

Yes. I only pointed out that if I Post for every row change, then
BeforePost can only validate data within each row, not any inter-row
relationships. In contrast, if I cache all changes I can do all the
validation and processing after the user is done, and then post
everything to the DB just once.

> "multi-generational architecture". That means your new row
> versions have two lives in the database:

I fully understand the power of MGA / transactions, but relying on
transactions as a sandbox for fooling around (ie. insert/update/delete
many times until a "deal" is finizlized) also has implications:
network traffic and server disk I/O.

In my particular case the server also has triggers that update a
summary table (per month/year/total), so each change in the detail
table ripples through another table.

> >I need to calculate (and store) a tax amount field which depends on
> >many application variables and uses a very twisted logic
> (tax laws...)
>
> Well, the complexity of the logic doesn't stop it being calculated
> and validated on the server side...where did you get the idea that
> it did?

It doesn't *stop* it from going server side, only it will make life
very hard. Debugging SPs isn't easy (even with emulators such as in
DBWorkbench), and the language misses a lot of conveniences found in
Object Pascal.

I agree that simple things like calculating a fixed rate VAT can and
should be done server side. But what to do when VAT rates depend on
the date of the deal, the location, the type of goods, the user should
be able to override it?

This requires a pretty comlicated SP that takes many parameters, and
has to communicate back to the application if there's some problem
that the user needs to address.

> ParamByName. Repeat-repeat-repeat, you cannot bind a client-side
> calculated field directly to a database field.

> >Those calculated fields that I mention are all "real" fields, ie.
> >columns in the table.
>
> They can't be BOTH real fields AND calculated fields.

My apologies. I think I mis-used the term "calculated fields". What I
meant is normal fields (ie. bound to table columns), that need to be
filled with calculated values.

> What this all means is that, if you're using the TDataset-compatible
> components, you need to get your head around how the ancestors work.

Now if only there was some real documentation from Borland...
But I'll read it once more.

Many thanks again.

Eyal