Conference orarep::nomahs::rally

2926.0. "DML failing due to F/R data changes??" by ORAREP::JRFVAX::FREDRICKSON (Rallyho lads!) Tue Feb 25 1997 12:17

    I had an interesting error condition come up the other day.  I wasn't
    expecting it, and I was wondering if someone could tell me why it
    happened, or at least what's the logic in it?  The condition happens
    under both RALLY V4.0-7 and V7.0-1.
    
    We had an ADL procedure running that did DML code similar to this:
    
    	DB_OPEN
    	DB_RESET
    	  dsd.key_field := previous_parent_key_var;
    	DB_QUERY
    	DB_GET_FIRST
    	IF (STATUS = 0) THEN
    	  CALL_CMD ('INSERT RECORD NEXT GROUP');
    	WHILE (STATUS = 0) DO
    	BEGIN
    	  form.child_field := dsd.field;
    	  DB_GET_NEXT
    	  IF (STATUS = 0) THEN
    	    CALL_CMD ('INSERT RECORD AFTER');
    	END;
    	DB_CLOSE
    
    We were inserting records (description) into a child group, using
    values referenced via the key value of a previous parent record.  As
    RALLY was stepping off of the parent record (via INS REC NEXT GRP), we
    generate the key for the current parent record that makes up the f/r
    join between the parent (Purch Req) and child (Description).  This is a
    technique we use to copy from one Purch Req to another; the current
    parent record is a 'new' Purch Req copied via "call_cmd ('copy
    record')" and the DML is to copy over child info.
    
    Well, our problem is one of timing.  The parent key is generated
    between the DML doing the GET_FIRST and the GET_NEXT.  Our problem was
    that we were only getting the first line of text stored in the child
    group.  Turns out that the DB_GET_NEXT was failing, with the following
    error message:
    
    "A DB_GET_NEXT operation has not been performed because a DB_GET_FIRST
    is required for the first read operation, after each DB_QUERY, and [MORE]
    whenever the record changes at upper levels of related groups.
    ADL execution error  14667."
    
    To be honest, this threw me for a loop.
    
    *** whenever the record changes at upper levels of related groups. ***
    
    Why would DML care about the form/report transaction?  Isn't it
    completely independent from it, having it's own attach and transaction
    stream?  I'm an somewhat confused...
    
    We fixed the problem by generating the parent key not by leaving it via
    the INS REC NEXT GRP, but in the ADL prior to the DB_OPEN.  
    
    Any feedback on this issue would be appreciated.
    
    Steve