Validation Hooks in BE or DataAccess Cancel The title field is required!

1. Roger Blanchard

   

   381 posts
   Registered:
   29 Jun 2018
   08 Jan 2019

   Link to this post

   Is it not a good idea to use ValidateData in the BE or the validation hooks in the Dataaccess class for assigning our own sequence values? We have built our own sequence table over the years instead of using the DB sequences and in our current framework we assign the values in our validation hooks.
   
   In the code below which is located in our PurchaseOrderDataAccess.cls if we assign the ePurchaseOrder.OrderNum it causes a second iteration of the FOR EACH ePurchaseOrder loop even though there is only one record.
   
   
   /*------------------------------------------------------------------------------
           Purpose: Validation method for ePurchaseOrder
           Notes:  
       ------------------------------------------------------------------------------*/
       METHOD PROTECTED VOID ePurchaseOrderCreateBeginTrans ():
        
           Consultingwerk.Util.BufferHelper:FindAfterBuffer (BUFFER ePurchaseOrderBefore:HANDLE) .
          
           FOR EACH ePurchaseOrder:
            
            IF ePurchaseOrder.OrderNum EQ 0 OR ePurchaseOrder.OrderNum EQ ? THEN
            DO:
             ASSIGN
              ePurchaseOrder.OrderNum = (NEW Osprey.Pos.ProgSys.ProgSysUtil ()):GetOrderNum ().
              
            END.
            
            CATCH e AS Progress.Lang.Error:
       LogManagerWrapper:WriteError(e).
      
      END CATCH.
            
           END.
          
       END METHOD .
2. Mike Fechner

   

   319 posts
   Registered:
   14 Sep 2016
   08 Jan 2019 in reply to Roger Blanchard

   Link to this post

   Only the validation methods (although I don't like that term that much) in the Data Access class are executed as part of the Database transaction. 
   
   So for assigning Sequences that should only be allocated once all business logic validation (in the Business Entity) have passed the Data Access validation methods are the place to be. 
   
   The other think I code here is related to referential integrity (when not using the SmartRelation's). Actual validation very often does not need to happen within the database transaction.
3. Roger Blanchard

   

   381 posts
   Registered:
   29 Jun 2018
   08 Jan 2019 in reply to Mike Fechner

   Link to this post

   I agree with not liking the term. They are really (to me) transaction hooks (Begin/End) and we have our own (Pre/Post). 
   
   As far as my original question then. In the DataAccess method it is normal for the FOR EACH TT to iterate twice if we change a field?
4. Mike Fechner

   

   319 posts
   Registered:
   14 Sep 2016
   Answered

   08 Jan 2019 in reply to Roger Blanchard

   Link to this post

   Have you tried a PRESELECT query ?
5. Roger Blanchard

   

   381 posts
   Registered:
   29 Jun 2018
   09 Jan 2019 in reply to Mike Fechner

   Link to this post

   I have not but will this morning.
6. Carl Verbiest

   

   59 posts
   Registered:
   12 Oct 2018
   Answered

   09 Jan 2019 in reply to Roger Blanchard

   Link to this post

   I you change a field that belongs to the index used by a for each on a table (database or temp) you can get that record again if the new keyvalue is greater than the previous value, or lower for a descending index seqment.
   
   preselect will guard you from that.
   using another index can also help
   

    
7. Roger Blanchard

   

   381 posts
   Registered:
   29 Jun 2018
   09 Jan 2019 in reply to Carl Verbiest

   Link to this post

   Thanks Carl and Mike. PRESELECT did solve the issue as the OrderNum does belong to the unique primary index. I have used it on a DB table before but never on a TT.