Controlling "Read Only" ProE data in DDM

[deedub777]

A question for ddm users...

How do you handle your read only data once it has been released (state change) in ddm?

Here's the workflow:

1. Designer updates the ProE data and saves to database at state of WORK. (or any state that designers have modify permissions on)
2. Designer sends package of data to an approver (who may only be using ddm office).
3. Approver then releases the package to state RELEASED (in ddm office). NB This state is read only to all users to prevent overwriting RELEASED data.
Released cycle complete.

Designer then wishes to work with the RELEASED data for another reason. Here's what happens:

Designer opens released data in ProE and ddm 'notices' that the native file attributes are different to the ddm metadata (as Release task was performed in ddm office) so ProE saves a new copy of each file in the working folder.

As the data opens in ProE it saves each individual file (locally in the working folder) and depending on the size of the assembly, takes a considerable time to load (an assembly we have that takes typicially 2 mins to load, now takes 3/4 hour).

Now here's the crunch, as the designer saves the file, he does not have permission to save back to ddm the updated attributes because of the (correctly) set ACLs for a RELEASED object. Next time the assembly is loaded into ProE, the whole re-save scenario starts again.

So how are you doing this? Is there a simple work-around I have missed?

The important underlying requirement though, is no-one has access to modify RELEASED data. This protects the data from inadvertant changes.

Any contribution greatly received.

 

[techies63]

We have recently purchased DDM and are very interested in the responses you get to this question.
<?:namespace prefix = o ns = "urn:schemas-microsoft-comfficeffice" />
Our situation is different then yours

 

[engineer98765]

deedub777 -

We don't use DDM - but we have been following discussions related to it as we are considering alternatives to Intralink.

Have you brought your situation up with DDM tech support? You must be doing something wrong. I can't believe that something that used to open in 2 mins now takes 3/4 hours!

 

[deedub777]

Hi engineer98765,

In answer to your question, yes I did bring this up with their support team and yes, they are working on it. I posted in order to cast the question much wider for open comment.

The assembly was, I believe, a unique case as the whole data set of our current project was imported and changed to RELEASED status in one hit so this case should be the exception rather than the norm (unless you release 100+ parts, drawings and assemblies in one hit).

CSI (providers of DDM) have confirmed my current workaround (see below) is OK for now while they look into a longer term solution.

Here's the workaround:
CSI tech: make a temporary modification to your ACL to allow the overwrite at a

 

[techies63]

deedub777 -


We see the problem as more significant than an unique case.


The way DDM works right now, if the only change that takes place after a DDM save is change to RELEASED status, then the REFRESH_PARAMS flag gets set to 'Y'. Each time the object is loaded after this occurs DDM willsave a "params.out" file, reset the parameters in the object and resave the object - all increasing load time.


The effect is cumulative. If in your example, instead of releasing 100 objects at a time - each of the 100 objects were released one-by-one over time - the results would be the same. Serious performance slowdown.


We are testing a trigger that we have placed on the table where parts and assembly data gets saved in the DDM database (dbo.parts).


It is designed to not change the value of REFRESH_PARAMS on a state change to RELEASED. If REFRESH_PARAMS was "Y" then it will remain "Y". Assuming no other change occurs after a save to DDM, (saving to DDMcauses REFRESH_PARAMS to be set to "N"), then REFRESH_PARAMS will remain "N" when released.


This will be our fix for the performance issue until DDM comes up with something better.

 

[deedub777]

techies63,


Just picked up your reply (email notification doesn't seem to work for me).


Anyway, you seem to have a much better grasp and understanding of how the database works. I have not taken too much time to delve any deeper myself but would ask if you have you discussed this solution with CSI?


It would be a good idea to post this on the ddm forumhttp://www.designdatamanager.com/forumindex/ where CSI staff monitor and respond directly.


I have spent some more time working out what to do. Saving the released status objects does need the "force ddm save" option temporarily enabled as saving the top level does NOT save if only attribute changes have taken place.


NOTE: force ddm save option requires a ProE restart to take effect.

 

[techies63]

I haven't looked much at the ddm forums. But that sounds like a great idea! I'll put our trigger out there next week sometime in case you are interested.


We did briefly discuss a trigger as a solution with CSI and at the time they did not indicate that it was a bad idea.


But it would besmart to get some direct feedback from CSI onour trigger before we use it for production.