web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Finance | Project Operations, Human Resources, ...
Unanswered

Custom attachment entity using DocuRefEntity as root — GET returns empty, POST returns RecId 0

(0) ShareShare
ReportReport
Posted on by 113
Hi everyone,
I am building a custom OData data entity to expose document attachments for a custom table called MPWorkerTransHeader (from a custom module), similar to how CustomerAttachmentsV2Entity works for CustTable.
 
My entity setup:
- Root datasource: DocuRefEntity
- Joined datasource: MPWorkerTransHeader (IsReadOnly: Yes)
-MPWorkerTransHeader joined with HcmWorker
- Relations on MPWorkerTransHeader:
  - DocuRefEntity.RefRecId == MPWorkerTransHeader.RecId
  - DocuRefEntity.RefTableId == MPWorkerTransHeader.TableId
  - DocuRefEntity.RefCompanyId == MPWorkerTransHeader.DataAreaId
- No ranges defined
- IsPublic: Yes
- Entity class only has postLoad() to populate FileContents virtual field
 
The problem:
1. GET returns empty even when I manually insert a DocuRef record via SQL with the correct RefTableId and RefRecId pointing to MPWorkerTransHeader
2. POST returns: "Write returned RecId 0 for table row of type 'MPWorkerTransDocumentAttachmentEntity'"
 
I noticed that DocuRefEntity has:
- IsPublic: No
- Tags: Internal use only
 
My questions:
1. Is DocuRefEntity meant to be used as a root datasource for custom entities, or is it truly internal only?
2. Why would GET return empty even when the DocuRef record exists in SQL with the correct RefTableId?
3. For POST, why does Write return RecId 0 when DocuRefEntity is the root datasource?
4. Should I use DocuRef table directly as root instead of DocuRefEntity?
 
Any guidance is appreciated. Thank you
Categories:
I have the same question (0)
  • Raed Bzour Profile Picture
    113 on at
  • Martin Dráb Profile Picture
    239,234 Most Valuable Professional on at
    You need to do more work on the problem isolation. For example, maybe you data entity never returns any data and therefore testing the OData service isn't worth the effort, because it can't work either. Or maybe you'll find that the entity is correct and you indeed has a problem with OData only, e.g. because you query a wrong company.
     
    I would begin with opening SSRS and querying the underlying view there. If it doesn't return any data, I'd then open the view defining and analyze the query, e.g. whether all join conditions are correct. There you can also play with the query, e.g. checking if you start getting data if you remove a joined table.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Introducing the 2026 Season 1 community Super Users

Congratulations to our 2026 Super Stars!

Meet the Microsoft Dynamics 365 Contact Center Champions

We are thrilled to have these Champions in our Community!

Congratulations to the March Top 10 Community Leaders

These are the community rock stars!

Leaderboard > Finance | Project Operations, Human Resources, AX, GP, SL

#1
Giorgio Bonacorsi Profile Picture

Giorgio Bonacorsi 653

#2
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 501 Super User 2026 Season 1

#3
CP04-islander Profile Picture

CP04-islander 298

Last 30 days Overall leaderboard

Product updates

Dynamics 365 release plans