OLE Notes were updated in GP2015. Attachments are now stored in SQL tables as BLOBs (Binary Large OBjects) - dbo.CoAttachmentItems.
Supporting that are CO00101, CO00102 and CO00105.
These are the main challenges:
The BusObjKey stores a complex 4 part key that links to the GP record (master or transaction). In classic GP style, there are different rules for objects from GL vs AR vs AP and Master record attachment vs transaction attachment. sometimes the key is 3 segments.
File types of the document must be determined from the blob. CoAttachmentItems.FileName contains the full path and filename of the docment when it was imported. (CO00105.Filename does not store path) Filenames may be truncated if the length exceeds 255 chars, hence you cannot rely on this field to determine file type. CO00105.FileType is also not reliable. (We have seen blanks). You may delete the "source" file once it is imported.
For performance reasons, your report design must be event driven - the attachment should be retrieved only when the user clicks on a link to retrieve it. otherwise you will bog the system.
Then finally, how to display the file. In Mercury, we stream the blob, detect file type from the header, save it to a temp file and open the file in the appropriate application in a separate process.
While it may be possible to do this in SSRS, it is going to be a bit of a slog. it took us a while to figure this out and get attachments from any module, any file type to open with our reports. (at least the ones we have encountered...)
This new Attachment feature is an improvement over the old legacy OLE Notes. Two criticisms encountered are:
a. It takes far too many clicks to get to a document attachment. if you have more than a few to review at one time, this gets old.
b. Admins complain of database bloat. I have seen databases double their size in a year.