BDCP2 table — Change Pointer Lock Table for ALE Processing
BDCP2 is the shadow or reservation table used by the ALE change pointer conversion job to mark which BDCP entries a given run has claimed for processing, so a second parallel run does not pick up and convert the same change pointer twice. A row disappears once the corresponding IDoc has been generated and the source BDCP entry is flagged as processed.
BDCP2 sits alongside the standard change pointer table BDCP and exists purely to prevent duplicate processing when multiple background jobs convert change pointers into IDocs at the same time. Interfaces consultants meet it almost exclusively when change pointers appear to be logged but never turn into outbound IDocs, usually after a job was cancelled mid-run.
Published 15 Sept 2026· 991 words
What it stores
A row in BDCP2 represents one change pointer entry that a change-pointer-processing run has claimed for conversion into an IDoc, at the moment it was picked up from BDCP. The row acts as a working reservation: while it exists, no other parallel execution of the same processing job is allowed to select and convert the same underlying change. The content of the row mirrors the identifying key of the BDCP entry it shadows, so the process can match the reservation back to its source when the run finishes. Under normal operation the row is short-lived, created at selection time and removed once the corresponding IDoc has been successfully generated and the original BDCP entry has been marked as read. Rows that persist beyond a normal job runtime indicate a run that never completed and released its claim.
Key fields
- MANDT - client, always restrict on this before anything else
- CHANGENR - change pointer number, the link back to the corresponding BDCP entry
- TABNAME - name of the application table whose change created the pointer
- TABKEY - key of the changed record in that application table
- FDNAME - name of the changed field that triggered the pointer
- MESTYP - message type the change pointer is destined to feed
How it joins the data model
- BDCP2-CHANGENR = BDCP-CHANGENR to find the source change pointer a reservation belongs to
- BDCP2-MESTYP = TBDLS-MESTYP to check whether the distribution model still expects that message type from that source
- BDCP2-TABKEY joins back to the key field of the changed application table itself, for example the customer or material number
- once conversion succeeds the message type flows into EDIDC-MESTYP on the IDoc control record that the run creates
- EDIDC-DOCNUM = EDIDD-DOCNUM to see the actual segment data produced from the change pointer once it clears BDCP2
How to read it safely
Always restrict on MANDT first, the table is client-dependent and mixing clients in a selection produces meaningless counts. In a healthy system BDCP2 is small or empty most of the time, since rows exist only for the duration of an active processing run. A large or steadily growing row count is itself the finding, it does not need further slicing to be meaningful. When investigating a specific object, narrow by TABNAME and TABKEY together rather than scanning the whole table, since TABKEY alone is not unique across different source tables.
How to prove it in the data
Symptom: a master data change was made hours ago, the change pointer was logged, but no outbound IDoc appeared for that message type. Select BDCP2 on MANDT, TABNAME, and TABKEY for the changed record. A row still present with an old timestamp on the related BDCP entry confirms a stuck reservation from a job that never completed, rather than a distribution model or partner profile problem.
ECC vs S/4HANA
The classic ALE change pointer mechanism, and BDCP2 with it, is still present on S/4HANA for scenarios that continue to rely on change-pointer-driven IDoc distribution, such as many master data replication flows that have not been migrated to newer integration patterns. There is no compatibility view replacing it and no structural change of note. Where a scenario has been re-platformed onto event-driven or API-based replication, change pointers and BDCP2 simply stop being written for that message type rather than being replaced by an equivalent object.
Common pitfalls
- Assuming a row in BDCP2 means the change pointer was successfully processed. It means the opposite while it is unresolved, it means the change is currently claimed and blocked from being picked up again.
- Deleting stuck BDCP2 rows manually without checking whether an IDoc was already partially created for that change pointer. This can either lose the change entirely or, worse, cause it to be processed twice once cleared, depending on where the original job actually failed.
- Treating an empty BDCP2 as proof that change pointer processing is healthy. Empty just means nothing is currently mid-flight, it says nothing about whether BDCP itself still holds a large unprocessed backlog.
- Confusing BDCP2 growth with a change pointer volume problem. Growth here usually means a job crashed or was killed, not that more changes are being made in the source system.
- Investigating BDCP2 before checking whether the relevant message type is even active in the distribution model. If the message type was switched off, entries never reach BDCP in the first place and BDCP2 is irrelevant to the symptom.
- Restarting the change pointer processing job repeatedly without clearing the orphaned reservation first, on the assumption that a rerun will simply pick up the pending change. If the reservation is still held, the rerun skips exactly the record under investigation.
Whose problem this is
This is interface or basis territory, not a functional master data question. The functional team owns whether the change pointer was correctly created for the object in question, but a stuck or oversized BDCP2 is a job scheduling and background processing issue, usually traced back to a cancelled or timed-out change pointer conversion run.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/bdcp2ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.