I have a dispatch script that is activated During Check out (Before check out change has occurred) that compares the %NameOfLoggedInUser% to the datacard variable Owner. If they don't match, Solidworks executes "Cancel Solidworks Enterprise PDM Command" and returns an 'Access Denied' message. This works well for most files but every now and then I get a file that returns N/A for the Owner, despite the fact that %NameOfLoggedInUser% = %Owner% is true. Has anyone any insight why this might occur?
As a sanity check, I created another Dispatch Menu command "WhoIsOwner" to make sure the variable Owner is readable and valid. When invoked, it returns the expected value for Owner and it's not N/A.
It may be the configuration Jason.
Referring to files that support configurations:
I've seen dispatch fail to run when called during automatic transitions. At other times, I have seen it fail when when the "<configuration name>" is omitted. Then again, there are yet again other times in standard transitions the dispatch works fine without the configuration name. If the data is not sanitized, the problem could be not always having consistent configuration names.
Safest bet, use the configuration name when pulling the data card variable.
Hope this sheds some light,
Tim CEPA
I specified the configuration for the variable Owner as per your advice Tim, but I still occasionally get N/A on select files. I can't help wonder if the dispatch script is running at a different pace than the action that invokes it (just before Check out) somehow narrowing the window opportunity to read %Owner% resulting in "N/A" to be returned.
2 things:
Thanks
Tim CEPA
Also, does the %Owner% field update all configurations?
It turns out that the problem stems from the custlists associated with the files in question. When the Dispatch program runs, it runs "For all documents" and the Custlist appears as a reference document for the files, even though they can't be processed separately from the part. After the script does the compare of %NameOfLoggedInUser% with %Owner% on the part file, it does so on the custlist which returns "N/A". The solution was to create an additional jump that grants access on "N/A". Protection is retained since the cutlist could not be processed if the %NameOfLoggedInUser% didn't = %Owner% on the prior jump.
Whew!!
It turns out that the problem stems from the custlists associated with the files in question. When the Dispatch program runs, it runs "For all documents" and the Custlist appears as a reference document for the files, even though they can't be processed separately from the part. After the script does the compare of %NameOfLoggedInUser% with %Owner% on the part file, it does so on the custlist which returns "N/A". The solution was to create an additional jump that grants access on "N/A". Protection is retained since the cutlist could not be processed if the %NameOfLoggedInUser% didn't = %Owner% on the prior jump.
Whew!!