Forum Post: ProDataset MERGE-CHANGES copy-all-mode unexpected behaviour?

  • Thread starter Thread starter Mike Fechner
  • Start date Start date
Status
Not open for further replies.
M

Mike Fechner

Guest
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.

Continue reading...
 
Status
Not open for further replies.
Back
Top