Ken Bailey wrote:
> Michal,
> You can use TQuery's with filtering to perform the master/detail. In the
> master tables datasource OnChange event dop something like this:
> if (field = nil) then
> begin
> sFilter := {define the filter here}
> if sFilter <> detaildataset.Filter then
> begin
> detaildataset.Filter := sFilter;
> Filtered := True;
> end;
> end;
> For example, in an order processing environment, you could have a master
> query that selected all the orders for a particular customer. The detail
> query would select all the line items from all the orders for that
> customer. The filter would then be on order #.
> Michal Bukovjan wrote:
> > Ken,
> > I actually get the event. TTable / Delphi behaves right, because when the
> > OnUpdateRecord event is assigned, the implicit update through linked TUpdateObject
> > won't occur and I have to call TUpdateObject.Apply(TUpdateKind) myself.
> > This works - whether there is an event or not, the records are updated (if I call
> > the Apply for TUpdaeSQL).
> > After applying updates, though, the records that were added or records whose
> > primary key fields were modified show up twice in the TTable (actually, in the
> > grid linked - this may be a TDBGrid bug after all... I'll check that right away
> > but it's improbable).
> > When I reopen the TTable, the same records are seen just once, which should be if
> > there were not for the bug in BDE or Delphi. (I guess).
> > I need to use TTable with cached updates because I have to let the user decide
> > which changed records actually write to the database and which should be just left
> > as is, or allow the user to just cancel the changes if he wishes so.
> > Normally, I would have used TQuery because TQuery works well with cached updates,
> > however, there is master - detail relationship, and if changes are made to detail
> > records, and the detail is TQuery, changing the master record will re-open the
> > TQuery which discards any changes made. TTable uses some internal ranges, and no
> > matter how the master changes, the detail changes remain intact, which is the
> > behavior I need..
> > As an example, I can use Database Exlorer
> > Master table - List of tables
> > Detail table - List of fields in tables
> > If I changed field definition in table 1 (it would turn green), then, before
> > applying, switched to table 2 and back to table 1, changes I made would be lost if
> > TQuery was used. If using TTable, changes are still there..
> > Thanks for your time,
> > Michal Bukovjan
> > Ken Bailey wrote:
> > > Michal,
> > > You should be getting the event if cached updates is true. Take a look
> > > at DBTables.
> > > Try this (overill):
> > > 1) Assign your event handler.
> > > 2) Create an event handler for OnUpdateError - just a showmessage.
> > > 3) Assign the updateObject.
> > > 4) In the AfterOpen event of the TTable, put in a showmessage showing
> > > the state of cachedupdates.
> > > Try it and see if you get an event.
> > > As an aside, why do you want to use cached updates?
> > > Michal Bukovjan wrote:
> > > > Ken,
> > > > The OnUpdateRecord looks like this :
> > > > begin
> > > > if <DatasetField>.AsString = 'Want to write this to the dataset now' then
> > > > begin
> > > > UpdateSQL.Apply(UpdateKind);
> > > > Action:= uaApplied;
> > > > end else Action:= uaSkip;
> > > > However, as I found, this is of no importance. As I tested that yesterday,
> > > > there is even no need for the OnUpdateRecord handler and the problem still
> > > > persist.
> > > > I posted a quick example how to reporduce this problem in
> > > > borland.public.delphi.database.desktop
> > > > Thanks for your interest,
> > > > Michal Bukovjan
> > > > Ken Bailey wrote:
> > > > > Michal,
> > > > > What does your onUpdateRecord event handler look like?
> > > > > Michal Bukovjan wrote:
> > > > > > I experience a strange behavior using TTable and cached updates.
> > > > > > I have a simple TTable linked to an Interbase table, I use persistent
> > > > > > field.
> > > > > > I have enabled CachedUpdates, and written an OnUpdateRecord event
> > > > > > handler, which looks what record is going to be updated, and either
> > > > > > applies the update (using a linked TUpdateObject component) or skips the
> > > > > > update.
> > > > > > The problem is, after the call to ApplyUpdates, every record replicates
> > > > > > and is seen twice in TTable !!!
> > > --
> > > Ken Bailey
> > > Falmouth Software Works Ltd.
> --
> Ken Bailey
> Falmouth Software Works Ltd.
