DatasetController Question
 
Forums / SmartComponent Library - Developer Forum / DatasetController Question

DatasetController Question

6 posts, 1 answered
  1. Roger Blanchard
    Roger Blanchard avatar
    413 posts
    Registered:
    29 Jun 2018
    25 Mar 2021
    Link to this post
    In the following method of my datasetcontroller should TRACKING-CHANGES for my TT be TRUE before I set it to TRUE. I am not in update mode from my viewer.

    After calling SubmitChanges shouldn't TRACKING-CHANGES be FALSE?

    METHOD PUBLIC VOID UpdateStat( piStat AS INTEGER ):

    DEFINE VARIABLE rRowid AS ROWID NO-UNDO.
        DEFINE VARIABLE oAdapter AS SmartBusinessEntityAdapter NO-UNDO.
        
    ASSIGN oAdapter = SmartBusinessEntityAdapter:FromDatasetController (THIS-OBJECT) .
             
        IF NOT VALID-OBJECT (oAdapter) THEN
            UNDO, THROW NEW AppError ("A SmartBusinessEntityAdapter needs to be associated with this DatasetController first.", 0) .
                 
        IF VALID-OBJECT (oAdapter:UpdatingSmartDataTarget) THEN
            UNDO, THROW NEW AppError ("The SmartBusinessEntityAdapter is currently in update mode.", 0) .
             
        IF eTagHdr.Stat = piStat THEN
        RETURN. /* no action required */
        
        MESSAGE "UpdateStat......TrackingChanges=" TEMP-TABLE eTagHdr:TRACKING-CHANGES
       VIEW-AS ALERT-BOX.
       
        TEMP-TABLE eTagHdr:TRACKING-CHANGES = TRUE.
         
        ASSIGN 
        eTagHdr.Stat = piStat
            rRowid          = ROWID (eTagItem).
     
        oAdapter:SubmitChanges ().
        
        /* Roger Blanchard / Osprey Retail Systems Feb 27, 2019
    If we are here then no errors were thrown from the backend 
    so lets refresh our bindingsource 
    */
        
        /* Refresh a single row */
        oAdapter:BindingSource:Refresh ().
      
        /* Reopen query in case the join between the tables might
           have changed */
        /*
        oAdapter:QueryHandle:QUERY-OPEN () .
        oAdapter:BindingSource:RefreshAll() .
        oAdapter:QueryHandle:REPOSITION-TO-ROWID (rRowid) .  
      */
     
      RETURN. 
     
        CATCH err AS Progress.Lang.Error :
        LogManagerWrapper:WriteError(err).
        UNDO, THROW err. // throw to caller to handle error 
            // Consultingwerk.Util.ErrorHelper:ShowErrorMessage (err) .       
        END CATCH.
        
        FINALLY:
    MESSAGE "UpdateStat (End)......TrackingChanges=" TEMP-TABLE eTagHdr:TRACKING-CHANGES
       VIEW-AS ALERT-BOX.
    END FINALLY.

    END METHOD.
  2. Mike Fechner
    Mike Fechner avatar
    342 posts
    Registered:
    14 Sep 2016
    25 Mar 2021 in reply to Roger Blanchard
    Link to this post
    Hi Roger,

    the SmartBusinessEntityAdapter keeps tracking changes turned on always. It just disables it around the merge/empty-dataset methods. And when a DatasetController is in use, the DatasetController's data is the one that the SmartBusinessEntityAdapter works on.

    What are you trying to achieve? 

    Mike 
  3. Roger Blanchard
    Roger Blanchard avatar
    413 posts
    Registered:
    29 Jun 2018
    25 Mar 2021 in reply to Mike Fechner
    Link to this post
    Okay, that makes sense for what I am seeing.

    When looking at the sample code on the dataset controller TRACKING-CHANGES was being set to TRUE. I assumed incorrectly we had to do that or that it would be FALSE.

    What I am trying to do is delete a TT record but not send the delete to the backend.

    In my sample below I was not setting TRACKING-CHANGES = TRUE but it is already set. Even though I am not calling SubmitChanges this delete is tracked and will be sent to the backend on the next Submitchanges.

    Do you see an issue with me setting TRACKING-CHANGES = FALSE at the beginning of the method and then to true in the FIANLLY?

    /*------------------------------------------------------------------------------
    Purpose: Used to simply remove a record from the grid without actually deleting
              the record from the DB. What we will do is delete the TT but do
              not call Submitchanges to the backend.
    Notes:
    ------------------------------------------------------------------------------*/

    METHOD PUBLIC LOGICAL RemoveFromGrid(  ):

    DEFINE VARIABLE rRowid AS ROWID NO-UNDO.
        DEFINE VARIABLE oAdapter AS SmartBusinessEntityAdapter NO-UNDO.
        
    ASSIGN oAdapter = SmartBusinessEntityAdapter:FromDatasetController (THIS-OBJECT) .
             
        IF NOT VALID-OBJECT (oAdapter) THEN
            UNDO, THROW NEW AppError ("A SmartBusinessEntityAdapter needs to be associated with this DatasetController first.", 0) .
                 
        IF VALID-OBJECT (oAdapter:UpdatingSmartDataTarget) THEN
            UNDO, THROW NEW AppError ("The SmartBusinessEntityAdapter is currently in update mode.", 0) .
            
        MESSAGE "RemoveFromGrid...TrackingChanges=" TEMP-TABLE eTagHdr:TRACKING-CHANGES
       VIEW-AS ALERT-BOX.
       
        DELETE eTagHdr. 
       
        /* Roger Blanchard / Osprey Retail Systems Feb 26, 2019
    This does not scroll the grid into position 
    */        
        oAdapter:QueryHandle:QUERY-OPEN () .
        oAdapter:BindingSource:RefreshAll() .
        /* Roger Blanchard / Osprey Retail Systems Feb 27, 2019
    We cant reposition to the Rowid as the row has been removed.
    The caller will reposition the grid 
    */
        // oAdapter:QueryHandle:REPOSITION-TO-ROWID (rRowid) .
        
        RETURN TRUE.   
       
        CATCH err AS Progress.Lang.Error :
        LogManagerWrapper:WriteError(err).
        UNDO, THROW err. // throw to caller to handle error 
            // Consultingwerk.Util.ErrorHelper:ShowErrorMessage (err) .       
        END CATCH.
        
        FINALLY:
    MESSAGE "RemoveFromGrid (End)......TrackingChanges=" TEMP-TABLE eTagHdr:TRACKING-CHANGES
       VIEW-AS ALERT-BOX.
    END FINALLY.

    END METHOD.
  4. Mike Fechner
    Mike Fechner avatar
    342 posts
    Registered:
    14 Sep 2016
    Answered
    25 Mar 2021 in reply to Roger Blanchard
    Link to this post
    That should be o.k. - dealing with the row-state is pretty flexible.

    Alternatively, you can also call ACCEPT-CHANGES or ACCEPT-ROW-CHANGES to wide wipe ROW-STATE. All possible. 

    Of course it's best to turn off tracking changes when doing updates that do not need to be tracked. 

    The backend only cares about modified rows. 
  5. Roger Blanchard
    Roger Blanchard avatar
    413 posts
    Registered:
    29 Jun 2018
    25 Mar 2021 in reply to Mike Fechner
    Link to this post
    Thanks Mike...I will give that a try.
  6. Roger Blanchard
    Roger Blanchard avatar
    413 posts
    Registered:
    29 Jun 2018
    29 Mar 2021 in reply to Roger Blanchard
    Link to this post
    Works great...thanks
6 posts, 1 answered