|Subject||Re: [IBO] Master-Detail dillemas with TIBO*|
> from Delphi's TQuery. That's the help you should look at -- albeitBorland's help isn't only minimal but also badly written in general.
> Borland's helpfile on this issue is minimal.
It usually explains what, but not how and why.
> just gonna have to *believe* it when I tell you that the detail'sOk, I believe :-)
> Datasource property provides the set-to-set datalinking for a
> TQuery/TIBOQuery detail/master relationship.
> Do you actually understand that Post writes to the database? Fb/IBYes. 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 rowI fully understand the power of MGA / transactions, but relying on
> versions have two lives in the database:
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 onIt doesn't *stop* it from going server side, only it will make life
> >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?
very hard. Debugging SPs isn't easy (even with emulators such as in
DBWorkbench), and the language misses a lot of conveniences found in
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-sideMy apologies. I think I mis-used the term "calculated fields". What I
> 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.
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-compatibleNow if only there was some real documentation from Borland...
> components, you need to get your head around how the ancestors work.
But I'll read it once more.
Many thanks again.