Mass association of Vendor Attachments by using a database update

(0) Share

Report

Posted on by Community Member

Hello-

I have about 5,000 vendors that we uploaded into AX 2012. We are now in need of having an attachment in AX for each one of vendors. I have everything configured to attach an item through the regular process, but we would like to do this in mass.

I have found things online regarding similar situations, but they have all required some alteration of a CLASS or something along code changing.

I want to know if there is a way just place all of the documents into the folder I have already setup for AX, but somehow link the docs to their corresponding vendor?

My idea was maybe perform a database update to the DocuRef table to make this happen, but I am not sure.

Thanks,
Phil

*This post is locked for comments

I have the same question (0)

All responses (3)

Answers (1)

Verified answer

Martin Dráb 237,795 Most Valuable Professional on at

Like (0)

Report
It would require coding as well. Does it mean that you're all right with writing T-SQL code, but not X++ code? What's the problem?

I wouldn't try to put it directly to DB for two main reasons:

You would have to deal with assignment of record IDs.

I have no idea how exactly AX stores binary data in database, i.e. whether you can easily do the same from SQL. Maybe there is nothing tricky, but it requires time for investigation and testing. (Assuming that you want to attach files and not just file paths.)

Writing a simple batch process in X++ that will read data files the folder and attach them to vendors (using usual AX APIs) is likely much less work, and without risks.

Was this reply helpful? Yes No
Suggested answer

Vilmos Kintera 46,149 on at

Like (0)

Report

The document folder for attachments works in conjunction with the DocuRef/DocuValue tables, that are linking the information to a specific table and record identifier in AX. If you want to mass-add attachments, you cannot avoid creating custom code to do this. It may be done in a Job, for which you do not have to do code release if you want to use it one-time.

In AX majority of the tables have a RecId unique identifier field, which you cannot easily generate in SQL directly without taking down the AX AOS due to caching the next available N RecIds. I agree with Martin that it is much less effort to just write an X++ job (or runbase/sysoperation class if you want to make it easily reusable, but that needs code release) to do the work in half a day.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Thank you Martin. I was hoping I would not have to get into X++ code, but it sounds like that is the simplest way.

Was this reply helpful? Yes No