Trapping A Record Is Locked Cancel The title field is required!

1. Roger Blanchard

   

   413 posts
   Registered:
   29 Jun 2018
   09 Nov 2018

   Link to this post

   Is it possible to trap that a record was not updated because it is locked by another user? I would like to have our code attempt to retry by refetching and trying to update addl times. 
   
   I am using the following;
   
   DEFINE VARIABLE oTagSales  AS Osprey.Host.TagSales.TagSalesDatasetModel NO-UNDO.
   
   /* ***************************  Main Block  *************************** */
   
   DO ON ERROR UNDO, THROW:
    
       oTagSales = NEW Osprey.Host.TagSales.TagSalesDatasetModel ().
    
       update_loop:
        DO WHILE TRUE:
     
           oTagSales:RetrieveData("eTagSales",
                                               "FOR EACH eTagSales WHERE StoreId = " + QUOTER ("001") + " AND ItemNum = " + QUOTER ("           1") + " AND PackNum = " + STRING (1) + " AND TagPrice = " + STRING (1.25) + " AND Period = 'D' " + " AND PeriodDate = " + STRING (TODAY) + " AND EmployeeNum = " + STRING (1) ).
                           
           oTagSales:TrackingChanges = TRUE.        
     
           IF NOT oTagSales:TagSales:Available THEN // record does not exist for today so lets create 
           DO:
               oTagSales:TagSales:Create().
               oTagSales:TagSales:StoreID   = "001".
               oTagSales:TagSales:ItemNum   = "           1".
               oTagSales:TagSales:PackNum   = 1.
               oTagSales:TagSales:TagPrice  = 1.25.
               oTagSales:TagSales:Period   = "D".
               oTagSales:TagSales:PeriodDate  = TODAY. 
               oTagSales:TagSales:EmployeeNum = 1.
           END.    
     
           oTagSales:TagSales:QtySales  = oTagSales:TagSales:QtySales + 1.
           oTagSales:TagSales:NetSales  = oTagSales:TagSales:NetSales + 1.25.
     
           DO ON ERROR UNDO, THROW:
      
               oTagSales:SaveChanges ().
      
               CATCH e AS Progress.Lang.Error:
       
                    /* Roger Blanchard / Osprey Retail Systems Nov 9, 2018
                          Can we trap the record is locked here so we can retry? The e:GetMessageNum(1) is returning a 0
                  */
       
               // IF e:GetMessageNum(1) = 11913 OR e:GetMessageNum (1) = 12300 THEN.
      
       IF VALID-OBJECT (oTagSales) AND oTagSales:HasChanges THEN
       DO: 
        MESSAGE "before next"
        VIEW-AS ALERT-BOX.
        NEXT update_loop.
       END.     
       
       MESSAGE
        e:GetMessageNum(1)  SKIP
        ErrorHelper:FormattedErrorMessages(e)  SKIP
        VIEW-AS ALERT-BOX.
       DELETE OBJECT e NO-ERROR.
      END CATCH. 
     END.        
     
     LEAVE.      
     
    END.                      
                          
   END.       
   FINALLY:
    DELETE OBJECT oTagSales NO-ERROR.      
   END FINALLY.                
   
2. Mike Fechner

   

   342 posts
   Registered:
   14 Sep 2016
   02 Dec 2018

   Link to this post

   Is it possible to trap that a record was not updated because it is locked by another user?

   
   
   Who should be in charge of retrying?
   
   For re-trying to get the lock, the lock-wait-timeout should be good enough. So when you finally get the record lock during the SAVE-ROW-CHANGES I don't see a need to retry the lock. You could just use a longer -lkwtmo parameter to increase the time. 
   
   But then typically I'm expecting error 11913 as a consequence when the record was modified by another user. We're catching that error and adding it to the record's error-string. 
   
   So depending on "who" should be in charge of retrying, you should look in to the record's ERROR-STRING property, for the message that equals the 
   
   Consultingwerk.OERA.Resources.OERACustomizer:RecordChangedByAnotherUser 
   
   string.
   
   
3. Mike Fechner

   

   342 posts
   Registered:
   14 Sep 2016
   02 Dec 2018 in reply to Mike Fechner

   Link to this post

   And consider trying the buffer's MERGE-BY-FIELD property. As this allows to ignore collisions on different fields. 
4. Roger Blanchard

   

   413 posts
   Registered:
   29 Jun 2018
   03 Dec 2018 in reply to Mike Fechner

   Link to this post

   I would be in charge of retrying x number of times.
   
   I will take a look at the records ERROR-STRING. 
   
   thanks.
5. Roger Blanchard

   

   413 posts
   Registered:
   29 Jun 2018
   03 Dec 2018 in reply to Mike Fechner

   Link to this post

   MERGE-BY-FIELD should already be set.
   
   thanks.