Board index » delphi » Master Detail and Master Inserts

Master Detail and Master Inserts

Two ADOQuerys linked via DataSource property. The detail one is used to look
up values from the master (uh-oh). One field to do the link. Everything
works fine when scrolling, even when editing the field in question in the
master table. As soon as the underlying TField updates its data the change
is reflected in the detail query (the record does not need to be posted!).
However when doing an insert in the master table this does not work. Doing a
bit of stepping in ADODB I could see no essential difference from the way it
works when editing. All the same calls with apparently all the same values.
The parameter has the correct value immidiately before the Requery is done.
However, the row returned then has all empty field values. Of course, when
coding parameters explicitely, everything works. Is there anyone with some
more insight into this or even with an explanation for this behaviour?
 

Re:Master Detail and Master Inserts


First I want to apologize that I forgot to sign my initial post.

I finally found TCustomADODataSet.InternalGetRecord where it says:

  if (Assigned(FParentDataSet) and FParentDataSet.Active and
     (FParentDataSet.IsEmpty or (FParentDataset.State = dsInsert))) or
     (MasterDataLink.Active and (DataSource.DataSet.IsEmpty or
                                (DataSource.DataSet.State = dsInsert))) then
  begin
    Result := grEOF;
    Exit;
  end;

I was daring and removed the condition 'or (DataSource.DataSet.State =
dsInsert)' and could not find any drawbacks so far (D5, W2K, MDAC 2.6). As
long as the linking field in the master table has no appr. value I get
exactly what I'd expect - an empty detail result set - and when there is an
appr. value I also get what I'd expect - the correct detail result set. No
errors or exception. However, I always expect people to have a reason for
writing one line more than required. So my question now is, why did they put
that in for in the first place?

TIA,

Reinhard Kalinke

Re:Master Detail and Master Inserts


Really noone with a thought or two? My code here now asks for dsEditModes
instead of dsInsert only and uses an additional function ParamsSupplied that
checks Parameters to be not null which might as well be a line or two more
than required but is working flawless so far.

function ParamsSupplied(Params: TParameters): boolean;
var i: integer;
begin
  Result := True;
  for i:=0 to pred(Params.Count) do
  begin
    if VarIsNull(Params.Items[i].Value) then
    begin
      Result := False;
      Break;
    end;
  end;
end;

function TCustomADODataSet.InternalGetRecord(Buffer: PChar;
  GetMode: TGetMode; DoCheck: Boolean): TGetResult;
begin
  if (Assigned(FParentDataSet) and FParentDataSet.Active and
     (FParentDataSet.IsEmpty or (FParentDataset.State = dsInsert)))
  or (MasterDataLink.Active and (DataSource.DataSet.IsEmpty or //RKMod
     ((DataSource.DataSet.State in dsEditModes) and not
ParamsSupplied(Command.Parameters)))) then
  begin
    Result := grEOF;
    Exit;
  end;

"Reinhard Kalinke" <reinhard.kali...@t-online.de> schrieb im Newsbeitrag
news:3ba23723_1@dnews...

Quote
> First I want to apologize that I forgot to sign my initial post.

> I finally found TCustomADODataSet.InternalGetRecord where it says:

>   if (Assigned(FParentDataSet) and FParentDataSet.Active and
>      (FParentDataSet.IsEmpty or (FParentDataset.State = dsInsert))) or
>      (MasterDataLink.Active and (DataSource.DataSet.IsEmpty or
>                                 (DataSource.DataSet.State = dsInsert)))
then
>   begin
>     Result := grEOF;
>     Exit;
>   end;

> I was daring and removed the condition 'or (DataSource.DataSet.State =
> dsInsert)' and could not find any drawbacks so far (D5, W2K, MDAC 2.6). As
> long as the linking field in the master table has no appr. value I get
> exactly what I'd expect - an empty detail result set - and when there is
an
> appr. value I also get what I'd expect - the correct detail result set. No
> errors or exception. However, I always expect people to have a reason for
> writing one line more than required. So my question now is, why did they
put
> that in for in the first place?

> TIA,

> Reinhard Kalinke

Other Threads