BDCP2 table — ALE Change Pointers (BDCP2)
BDCP2 stores ALE change pointers and is the preferred change-pointer table in NetWeaver 6.x and later. Each pointer records a change that may be relevant to one or more ALE message types for later processing, for example by RBDMIDOC or BD21. It is not a lock or reservation table and should not be interpreted as transient run ownership.
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 20 Sept 2026· 928 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
- Client and change-pointer identifier — identify the pointer uniquely.
- Message type or change-document context — determines which distribution process can consume the pointer.
- Changed application table, record key and field — identify what business data changed.
- Processing and creation context — use standard ALE programs to determine pointer status rather than deleting rows manually.
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
BDCP2 remains relevant in S/4HANA wherever classic ALE change-pointer-driven IDoc distribution is still used. SAP documentation explicitly describes BDCP2 as the change-pointer table. New event or API integrations may bypass this mechanism, but BDCP2 itself is not a lock table.
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.
Learn this properly
Lessons and topics
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.