In the DMT command line manual there is an option that is missing detail and examples on syntax. The manual states:
-ExportData Exports format of all imports to specified file
The name and description didn’t seem super clear to me and it’s also missing what arguments this flag accepts. After hacking on it a bit I learned that it has a mandatory Output Path argument. So I made an empty folder, got inside and ran it pointing at my current directory:
DMT.exe -ExportData .\
What I got in that folder is a .CSV file for each table you can hit with DMT. Inside those CSV files was not “Data” as the command would have you believe. It was the metadata you see when you hit the Template Builder... button in DMT. It shows every field, name, type, format, valid values, and description.
So if you wanted that metadata in text form, this is how you get it.
I remember seeing/hearing about that command quite a while ago and thought it might be used to actually extract existing data from the database. Not exactly, but still maybe useful?
That’s what I’m looking for. The documentation makes it sound like you can use the DMT to download a table and upload it somewhere else (PILOT to LIVE for example). For that to be true you would need corresponding BAQs for every table supported by the DMT, with the correct field names to be accepted by the -Import command. Do we all have to make those BAQs by hand? I’m sure many people who have been using Epicor for a while have these already. For a new guy, I’m shocked I have to DIY.
Is there a shortcut to have BAQ’s use the field names instead of labels? It’d be nice if we didn’t have to rename them back to the field name every time.
Maybe someone here would take the challenge to make a powershell script to process those “templates” into the XML format of an exported BAQ. It could make the column labels match the names expected by DMT.
That is the exact passage I am talking about. They say “producing a file compatible with DMT imports” which is 100% dependent upon you creating a BAQ compatible with DMT imports. So my question is “Where do those come from and why aren’t they included?” Seeing how the DMT tables are clearly defined, shouldn’t we get matching BAQ templates? This is a lot of DIY that is performed by each customer. I know someone has already done it.
I’ll qualify this, I have never used the BAQ export method before, I have used PowerShell quite successfully in the past (based on the examples supplied).
I agree that having the BAQs included based on the minimum requirements of each DMT template would be very helpful. Even just for examples to build further on. In theory you only need the columns that Epicor denote as “Required”, although that’s not always the case.
I think I have seen some example baqs around, just can’t remember where. I agree that is a lot of DIY, but I can imagine, one BAQ would be ok for one customers requirements, and not another.
If the idea is to be able to export data from one environment for import into another, there’s a million pitfalls. For example, if you export the whole part table, it will include partClass and prodGroup. If the target system doesn’t have those Classes and Groups already setup then importing that Part info would fail…
This is exactly what I am talking about. These things are known, by Epicor. They should give sane templates that contain not only the required fields, but the common material fields that would need to be copied over. Excluding the fields that you obviously don’t want to copy. Naturally, these templates could then be modified by each customer to include anything specific to the environment. This takes intimate knowledge of the database tables that new customers would not have.
I depends an the context, and what is deemed acceptable. If you are synching data then you could argue that the edge cases like missing partClass and prodGroup, you may only run into those issues occasionally, and that’s ok fix the missing master data and re-import the missing records from the error output. if you are trying to standup a whole system new system via this method that’s another conversation.
Occasionally I think that too many of us me included are looking for the easy button. If we all had unlimited budgets I’m sure that DMT could be honed to perfection. Where do you stop. Epicor provided the BAQ feature which I think is useful, but they can never know what columns each individual customer will want. Getting back to @A9G-Data-Droid said it would be helpful for the DMT templates to have a bit more guidance than just the required fields. Even an included solution of related BAQs would be a helpful adjunct. If you are syncing systems (Live to Pilot), you could argue that Backup/Restore is a simpler path, and maybe that’s why there has not been too much further work around the DMT BAQ feature.
I can’t even count the number of hours I have spent with DMT since E9 and later versions, but what I can say it is a substantially better piece of software than it was compared to E9.
There are some pseudo-required fields. They’re not actually required for a successful DMT import, as defaults will be applied. But allowing the default to be used can have irreversible consequences. UOM Class is not required for the Part upload, because the system will have a default UOM Class -which has its own default UOM.
