Hi,
We are still using Rhythmyx 5.71 (yeah I know:o) ) However, we need to remove large quantities of content from our site via sql on the back end. Other than changing the workflow statuses from published to unpublished what issues should I be aware of as regards entries in related tables (such as PSX_RELATIONSHIPS etc…)?
Many thanks,
Jeff.
Jeff, of course you know you should never go messing in the back end database…
However, if it were me and I was forced to do it with a gun to my head I’d probably do just as you say - update the workflow state of the content item in the contentstatus table.
Ideally you’d want to create rows in the contentstatushistory table so that there’s an audit trail in place. You could create dummy rows in this table to make it look like you transitioned the items from Public to Archive (if there is a transition between those states in the first place). To be honest this stop isn’t really necessary, but would be recommended to ensure that it looks like you didn’t do anything in the back-end. Just don’t tell technical support what you’ve been up to!
I believe that the relationship tables will be fine left alone.
Cheers David!
How are things with you these days - getting into the sea at all?
The trouble with Rhyhmyx is that if you need to unpublish a huge load of content (we are completely taking one of the larger schools out of Rhythmyx) it is a nightmare of a job to go into every sub-folder and manually change the states - especially as we have literally hundreds of communities which means swapping every few minutes. The only feasible way of doing it for us is with a bulk update.
Anyway thanks for the advice about the content status history table.
Another thing occurs to me in that I could just set the expiary dates for all this content via sql too.
If all the content is under one top level folder you could use the search in folder option make sure that unlimited results is checked and sort by community then unpublish things community by community. I think you can only select batches of 200 at a time. We use this method, it saves having to muck around in the database
Kevin
Thanks keevan will have a look at that.
I really like the sound of this idea. Just updating the one field in the contentstatus table (if you know the ID’s of the content items to update in the first place) and letting RX take care of transitioning the item to an archive state. Genius.
Kevin - yeah, going through a search in folder would be really handy as well if you want to do it through the front end (i.e., the supported way 
Search in Folder was broken in 6.7 if you had a rather “deep” directory tree. This appears to have been fixed by patch RX-16289.
As we will be removing all the content then I only need supply the workflow ids (and know which number corresponds to unpublish in those workflows).