Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily.
X
Have you tried to use SQL scripts to move WTParts from one Library Context to another one?
Just interesting to check out if anyobody tried to use SQL scripts to move WTParts from one Library Context to another one and after the moving is done to delete the old Library Context.
I would say that we are investigating SQL option of moving parts . Even if write a java code we still need to identify how we can test solution that Windchill will be not broken. D
Even though it may be possible to use SQL, I recommend using the API, Recently we have moved lots of items (Documents) from couple of Contexts (Libraries) to multiple contexts using the API. The whole thing went smooth except for the items that are checked out.
My only complaint is about the moving items in bulk (using collections). If you use them, you could gain lot of efficiencies but even if one fails, it rolls back all of the items that are being moved in the collection.
If you have access to the codebase locally, you can write a Java client that will do the work of the move. You can feed it a list of numbers (that you can get from SQL) and have it churn away. Not posting code to the server and rebooting. Using the API should not break Windchill. I use them a lot for renames or set states where I have a list of parts.
What about the Change Objects that were created against the library context? What will be the procedure to move Change Objects (PRs/CRs/CNs/CAs) to another Library Context?
I mean using SQL not a java API. I think I just lazy to turn on logging debug info to trace SQL that is executed during Move action from PDMLink interface. Just want to check if anybody used SQL for it (the use of QuerySpec should be the same as SQL)
Eventually it all goes to some kind of SQL, just not sure why you would want to use it, even with the verbosities enabled. When I used SQL, I left out the fact that I used info from same folder and same object type in the destination container.
I did this for the sake of time and it was a development server, so the data didn't matter.
If using a given SQL recipe works today it may well not work tomorrow -- it's a fragile approach in which it is easy to miss something (e.g. when the case you traced does not contain all the different data cases for starters) and really mess up your data.
Going behind the API and modifying data directly with SQL is not supported for just such reasons. The supported approach is to use the API.
With verbosity enabled we can see the final SQL that was generated from Persistence API. So we can see the relationships/dependencies between the tables. Again there is no documentation that explain how Tables are linked together and if you updating one table what other tables have to update as well. At least this is my understanding. Of course I can be wrong. Thanks, Dmitry
Yes if the API says "supported API true" in javadocs.
Otherwise, no.
And yes, SQL or Java, you have to test your logic first.
Besides I think move is in EnterpriseHelper or something like it. (Not at my computer right now) Building your collection of parts is the logic you would have to write.