CDC "continuation" records - Forum - OpenEdge RDBMS - Progress Community

CDC "continuation" records

 Forum

CDC "continuation" records

This question is not answered

Does anyone just happen to have an example (hopefully using sports2000) that demonstrates how to trigger the circumstances that would result in CDC populating _Continuation-Position, _ArrayIndex, and _Fragment in, for instance, cdc_Customer?

I would have imagined that something like this would do the trick:

do transaction:
  find first customer exclusive-lock.
  customer.address2 = fill( " ", 800 ).
  customer.city = fill( " ", 72 ).
  customer.phone = fill( " ", 1000 ).
  message record-length( customer ).
end.

but, alas, it does not.

Extra credit if you can point me to the documentation that describes these fields beyond simply naming them.  Points subtracted if said documentation makes any reference to CDCTrackingHelper.  (I am trying to *create* split records - not put them back together.)

--
Tom Bascom
tom@wss.com

All Replies
  • Details, details...

    It turns out that you have to actually *change* the data and change all (or at least *most*) of the fields in the table.  This works:

    define variable c as character no-undo.

    do transaction:

     find first customer exclusive-lock.

     c = chr( random( 32, 127 )).

     name         = fill( c, 10 ).    /* idx */

     address      = fill( c, 4000 ).

     address2     = fill( c, 4000 ).

     city         = fill( c, 5 ).

     state        = fill( c, 4000 ).

     country      = fill( c, 10 ).    /* idx */

     phone        = fill( c, 4000 ).

     contact      = fill( c, 4000 ).

     salesRep     = fill( c, 10 ).    /* idx */

     comments     = fill( c, 10 ).    /* idx */

     creditLimit  = random( 1, 1000 ).

     balance      = random( 1, 500 ).

     terms        = fill( c, 4000 ).

     discount     = random( 1, 10 ) * 0.01.

     postalCode   = fill( c, 10 ).    /* idx */

     fax          = fill( c, 4000 ).

     emailAddress = fill( c, 3880 ).

     message record-length( customer ).

    end.

    Still looking for documentation though :)

    --
    Tom Bascom
    tom@wss.com

  • www.pugchallenge.eu/.../cdc---emea.pdf

  • Slide 24 at least mentions the fields but I think it is wrong.  When I run my code above I get 2 cdc_Customer records with the same seq#.  The _contunation field is 25 for one, 26 for the other but _fragment is 0 for both (_arrayIndex is also 0).  So _fragment does not seem to actually indicate "split record order".

    25 *seems* to be the _field-rpos of the last field prior to the split in the first fragment.  I'm not sure how reliable that is as an interpretation.  The _change-fieldmap seems unaware of the split.

    26 is the last remaining _field-rpos in cdc_Customer and the 2nd change record only has changes for that field although the _change-fieldmap seems to not know about any of them.

    So, thanks, that's a bit of an improvement on the documentation front.  But it is still pretty fuzzy.

    --
    Tom Bascom
    tom@wss.com

  • I mean it _is_ called *CHANGE* data capture  ;)
     
  • Yes, there is that ;) Let us not discuss how long it took me to realize that.

    I was wrong about the _change-fieldmap - it isn't that it doesn't know about the changes.  The problem is that there is only one _change-fieldmap shared by both changes.

    I may be on thin ice and suffering from a brain-cramp but I am not coming up with a way for there to be more than 2 fragments.  And if that is true I suspect that the 2nd fragment cannot have more than one field.

    --
    Tom Bascom
    tom@wss.com

  • More than 1 field *is* possible in the second fragment if the last few fields are smallish.

    But a maximum of 2 change records still seems valid.

    --
    Tom Bascom
    tom@wss.com

  • "_continuation" seems solved.  Thank you Libor and Peter!  :)

    _fragment and _arrayIndex are still a conundrum with _fragment apparently wrongly documented in the PPT that Libor pointed to :(

    --
    Tom Bascom
    tom@wss.com