ProDataset MERGE-CHANGES copy-all-mode unexpected behaviour? - Forum - OpenEdge Development - Progress Community

ProDataset MERGE-CHANGES copy-all-mode unexpected behaviour?

 Forum

ProDataset MERGE-CHANGES copy-all-mode unexpected behaviour?

This question is not answered
merge-changes-issue.p

Hi all, is this really expected behaviour? Tested on 11.5, 11.3 and 10.2B

I have a ProDataset with two tables, let's call them eCustomer and eSalesRep. eCustomer has a BEFORE-TABLE, eSalesRep does not.

I create two customer records and two salesrep records, turn on TRACKING-CHANGES for eCustomer and modify one record.

Then I get the changes dataset ...

hChanges:GET-CHANGES (DATASET dsCustomer:HANDLE, TRUE) .

and as expected the hChanges dataset contains a single customer record and no salesrep.

Then I use the MERGE-CHANGES method (directly without calling into any data access layer to process changes):

hChanges:MERGE-CHANGES (DATASET dsCustomer:HANDLE, TRUE) .

My expectation is, that MERGE-CHANGES copies data from the hChanges dataset to the dataset dsCustomer. In a real scenario this would update the client side eCustomer table with data updated during processing the changes on the AppServer. The copy-all-mode (the logical parameter) should control - to my understanding - that unmodified records (from tables with or without a BEFORE TABLE) from the hChanges dataset are merged into dsCustomer as well.

But why the heck, are the two unmodified salesrep records getting copied form dsCustomer to hChanges dataset????

And if - for what ever reason - that would be expected - why is the unmodified customer NOT copied in that direction as well????

I have a message before and after the MERGE-CHANGES:

MESSAGE "changes dataset" SKIP
"Customer" hChanges::eCustomer:TABLE-HANDLE:HAS-RECORDS
CountRecords(hChanges::eCustomer:HANDLE) SKIP
"SalesRep" hChanges::eSalesRep:TABLE-HANDLE:HAS-RECORDS
CountRecords(hChanges::eSalesRep:HANDLE)
SKIP
VIEW-AS ALERT-BOX.

Message before MERGE-CHANGES

changes dataset
Customer yes 1
SalesRep no 0

Message after MERGE-CHANGES

changes dataset
Customer yes 1
SalesRep yes 2

Source code attached.

Architect of the SmartComponent Library and WinKit

Consultingwerk Ltd.

All Replies
  • Is it because you are passing TRUE for the copy-all mode to MERGE-CHANGES?
     
    “When TRUE, the AVM merges all after-image table rows whether or not they contain changes. In this case, the temp-table in the original ProDataSet object must have a unique primary index that the AVM can use to find each corresponding row from the after-image table (since unchanged rows do not have a corresponding row in the before-image table). When a corresponding row is not found in the original ProDataSet object, the AVM creates a new row using the row from the after-image table. When FALSE, the AVM merges only after-image table rows that contain changes. The default value is FALSE.”
     
    Jeff Ledbetter
    skype: jeff.ledbetter
     
    From: Mike Fechner [mailto:bounce-mikefechner@community.progress.com]
    Sent: Friday, February 13, 2015 9:05 AM
    To: TU.OE.Development@community.progress.com
    Subject: [Technical Users - OE Development] ProDataset MERGE-CHANGES copy-all-mode unexpected behaviour?
     
    Thread created by Mike Fechner

    Hi all, is this really expected behaviour? Tested on 11.5, 11.3 and 10.2B

    I have a ProDataset with two tables, let's call them eCustomer and eSalesRep. eCustomer has a BEFORE-TABLE, eSalesRep does not.

    I create two customer records and two salesrep records, turn on TRACKING-CHANGES for eCustomer and modify one record.

    Then I get the changes dataset ...

    hChanges:GET-CHANGES (DATASET dsCustomer:HANDLE, TRUE) .

    and as expected the hChanges dataset contains a single customer record and no salesrep.

    Then I use the MERGE-CHANGES method (directly without calling into any data access layer to process changes):

    hChanges:MERGE-CHANGES (DATASET dsCustomer:HANDLE, TRUE) .

    My expectation is, that MERGE-CHANGES copies data from the hChanges dataset to the dataset dsCustomer. In a real scenario this would update the client side eCustomer table with data updated during processing the changes on the AppServer. The copy-all-mode (the logical parameter) should control - to my understanding - that unmodified records (from tables with or without a BEFORE TABLE) from the hChanges dataset are merged into dsCustomer as well.

    But why the heck, are the two unmodified salesrep records getting copied form dsCustomer to hChanges dataset????

    And if - for what ever reason - that would be expected - why is the unmodified customer NOT copied in that direction as well????

    I have a message before and after the MERGE-CHANGES:

    MESSAGE "changes dataset" SKIP
    "Customer" hChanges::eCustomer:TABLE-HANDLE:HAS-RECORDS
    CountRecords(hChanges::eCustomer:HANDLE) SKIP
    "SalesRep" hChanges::eSalesRep:TABLE-HANDLE:HAS-RECORDS
    CountRecords(hChanges::eSalesRep:HANDLE)
    SKIP
    VIEW-AS ALERT-BOX.

    Message before MERGE-CHANGES

    changes dataset
    Customer yes 1
    SalesRep no 0

    Message after MERGE-CHANGES

    changes dataset
    Customer yes 1
    SalesRep yes 2

    Source code attached.

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

    Jeff Ledbetter
    Product Architect | Roundtable Software

  • Jeff, I am not convinced….
     
    1st that would not explain, why the eCustomer in the changes dataset does still only contain a single record. Following your reading the eCusstomer in the changes dataset should contain two records. That would mean that the after-image for tables with and tables without a before-image table are treated differently.
     
    2nd The is all under the intro:
     
    “Merges the changed rows of all temp-tables or a single temp-table in a source ProDataSet object loaded with the GET-CHANGES( ) method into the corresponding rows of all temp-tables or a single temp-table (respectively) in the original (target) ProDataSet object.”
     
    …. Into the corresponding tows … in the original ProDataset …
     
    So there should not be any data-movement from source to change at all. This is MERGE-CHANGES, not GET-CHANGES
     
    3rd Imaging 100.000 eSalesRep records in the original dataset…. It can’t be a clever idea to copy them to a dataset (blowing up the DBI file) which most likely get’s deleted in the next line of code.
     
     
    Von: Jeff Ledbetter [mailto:bounce-jeffledbetter@community.progress.com]
    Gesendet: Freitag, 13. Februar 2015 16:33
    An: TU.OE.Development@community.progress.com
    Betreff: RE: [Technical Users - OE Development] ProDataset MERGE-CHANGES copy-all-mode unexpected behaviour?
     
    Reply by Jeff Ledbetter
    Is it because you are passing TRUE for the copy-all mode to MERGE-CHANGES?
     
    “When TRUE, the AVM merges all after-image table rows whether or not they contain changes. In this case, the temp-table in the original ProDataSet object must have a unique primary index that the AVM can use to find each corresponding row from the after-image table (since unchanged rows do not have a corresponding row in the before-image table). When a corresponding row is not found in the original ProDataSet object, the AVM creates a new row using the row from the after-image table. When FALSE, the AVM merges only after-image table rows that contain changes. The default value is FALSE.”
     
    Jeff Ledbetter
    skype: jeff.ledbetter
     
    From: Mike Fechner [mailto:bounce-mikefechner@community.progress.com]
    Sent: Friday, February 13, 2015 9:05 AM
    To:
    TU.OE.Development@community.progress.com
    Subject: [Technical Users - OE Development] ProDataset MERGE-CHANGES copy-all-mode unexpected behaviour?
     
    Thread created by Mike Fechner

    Hi all, is this really expected behaviour? Tested on 11.5, 11.3 and 10.2B

    I have a ProDataset with two tables, let's call them eCustomer and eSalesRep. eCustomer has a BEFORE-TABLE, eSalesRep does not.

    I create two customer records and two salesrep records, turn on TRACKING-CHANGES for eCustomer and modify one record.

    Then I get the changes dataset ...

    hChanges:GET-CHANGES (DATASET dsCustomer:HANDLE, TRUE) .

    and as expected the hChanges dataset contains a single customer record and no salesrep.

    Then I use the MERGE-CHANGES method (directly without calling into any data access layer to process changes):

    hChanges:MERGE-CHANGES (DATASET dsCustomer:HANDLE, TRUE) .

    My expectation is, that MERGE-CHANGES copies data from the hChanges dataset to the dataset dsCustomer. In a real scenario this would update the client side eCustomer table with data updated during processing the changes on the AppServer. The copy-all-mode (the logical parameter) should control - to my understanding - that unmodified records (from tables with or without a BEFORE TABLE) from the hChanges dataset are merged into dsCustomer as well.

    But why the heck, are the two unmodified salesrep records getting copied form dsCustomer to hChanges dataset????

    And if - for what ever reason - that would be expected - why is the unmodified customer NOT copied in that direction as well????

    I have a message before and after the MERGE-CHANGES:

    MESSAGE "changes dataset" SKIP
    "Customer" hChanges::eCustomer:TABLE-HANDLE:HAS-RECORDS
    CountRecords(hChanges::eCustomer:HANDLE) SKIP
    "SalesRep" hChanges::eSalesRep:TABLE-HANDLE:HAS-RECORDS
    CountRecords(hChanges::eSalesRep:HANDLE)
    SKIP
    VIEW-AS ALERT-BOX.

    Message before MERGE-CHANGES

    changes dataset
    Customer yes 1
    SalesRep no 0

    Message after MERGE-CHANGES

    changes dataset
    Customer yes 1
    SalesRep yes 2

    Source code attached.

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

    Stop receiving emails on this subject.

    Flag this post as spam/abuse.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Smells like a bug to me too.

    If you dump out the changes dataset after GET-CHANGES() and after MERGE-CHANGES(), they are different. I would not expect them to be, since the direction of the merge should be from changes --> dsCustomer.  

    hChanges:write-json('file', session:temp-dir + 'changes-1.json', yes, ?, ?, ?, yes).
    /* there's a changes-2 version for dumping after merge-changes() */

    changes-1.json has a single eCustomer record (plus the before-image tracking).

    changes-2.json has a single eCustomer record (plus the before-image tracking) AND 2 eSalesrep records.

    Note that this doesn't seem to be influenced by the copy-all-mode flag

    -- peter

  • Yes, this is a bug. We are not supposed to be copying data into the changed dataset. As a workaround, you can define a before-table for the child table (eSalesRep), and you will see the expected behavior.

    Please, report this via Technical Support so a bug can be logged.

  • Thanks Peter, thanks Fernando! Will log the case with ETSC.
     

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Case 00304041

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.