Two big changes starting with 10.2.500:
1.) DMT.exe (add the associated .dll) are distributed with EVERY client install. DMT is no longer a separate program. Your license key will enable DMT for your companies and the .lic file is no longer required.
2.) User Account Security Maintenance can enable DMT by user:
The license file isn’t needed in 10.2.300. It’s a “module level” item in the company licensing.
That’s right. .300. Sorry, working of .500 and it’s muscle memory now…
Extending on @markdamen’s comment…
The DMT didn’t give an error message on the RO issue above because in the UI, the field itself is greyed out and the user is prohibited from entering data there… so the UI would also not generate an error.
The DMT, in essence, is nothing more than an extremely fast typist entering data in the UI. It only has the logic that the UI has.
EXCEPT when it doesn’t (see above issue with BOO upload).
Why is my heart beating faster? Why did my AI just note that my serotonin levels spiked?
DMT should NOT be used by any “regular” users. It should only be used by “power” users who know what they are doing. Mass changes can be very dangerous. It is relatively quick and easy to completely wipe out lots of data within a few minutes.
Example (DON’T TRY THIS AT HOME!):
DISCLAIMER: PLEASE DO NOT DO THIS… it WILL modify all your descriptions. They WILL become all the same. you WILL corrupt your database. You will get fired.
Couldn’t be more clear. Handle with extreme caution and experienced users only. Got it.
Definitely a Career Limiting Move. In the words of Benjamin Franklin Parker, “With Great Power comes Great Responsibility” are your users ready for that?
Not at all lol. DMT will remain in the hands of IT only.
I have to take exception to this part. Is just containing incorrect info really considered a corruption? Especially when it was done on purpose.
If that’s the case, than my users “corrupt” the DB several times a day. 
If you do have some case where users would benefit from DMT, do it as an updatable dashboard instead. You can design in lots more control.
On a side note, does a DMT upload trigger any special BPM’s? Or does it just use the same ones using that the UI would trigger? If it did, there would be a way to validate them first.
If not, is it possible for the BPM to determine if it was called via DMT?
Maybe I was being a bit melodramatic. What I really meant to say is that all business circumstances are different and only you and your team can be the judge of how best to use DMT in your business, at the end of the day it did start off as a tool to get bulk data into the system without the need of the UI, but still follow the business logic (for the most part).
As multiple people have mentioned it can be a multiplier for error, but also a use bug finding tool.
A good example of this. If you enable TrackDimension (Track Multiple UOM) on the part and you have a lot of part non part specific UOMs in the class that you add to a part the PartUOM table grows significantly because it adds one row per part per UOM regardless of the UOM being part specific or not. Unfortunately unchecking the TrackDimension flag and updating the part does not reverse this. So you are stuck with either restoring the db (which is ok if you are in a data load phase) or building a sql query or baq that identifies the erroneous partUOMs and trying to delete witht he DMT (I can’t even remember if this works to be honest) So imagine if you had 80k parts and some part classes with 25 or more UOMs.
Might be worth a test to see what the call contextClient.AssemblyName value is if you use the DMT for a particulary update operation. Try running the Trace in the DMT (not sure if it shows that information) You may be able to create a bpm that sends a eventlog message to capture it.
hahaha… yes, you are correct… users corrupt data every day, but DMT just allows them to do it really fast.
STORY TIME: way back when I was in Tech Support, we had a user who said “we never mass change data”… I did a query, and found that there were over 100 jobs that were touched with the change within a 2 second period of time according to time stamps on trace logs.
“Never?”…
DMT will trigger BPMs… and BPMs can check the environment (ie… what program is being run), but this is not always foolproof. It depends on the application/module whether the current program is updated, and if not, then BPMs cannot tell…
That said, DMT “Might” update the current context.