I was looking at the Rhythmyx database tables where the content is stored (Just looking! Not trying to edit, I promise!). And it appears there are a lot of tables in there that are in a state that don’t make sense to me. For example, there are empty tables corresponding to content types that have been deleted from the system. More strange, I created a new shared field file, and I can’t for the life of me find a table that is storing the shared fields in that file, despite them being used in content types successfully. Everything in the Rhythmyx system seems to be working correctly. But the appearance of the database as it currently stands is confusing and doesn’t seem to match up with what’s actually happening.
Is this normal? Is our database in an undesirable state? Does Rhythmyx normally clean up this kind of thing at some point, or is there something I can do to cause it to clean things up? I’ve looked through the documentation for information on this, and have not found an answer.
In case it matters, we are using MS SQL Server, and I’m looking at the databases through SQL Server Management Studio.
Lucky you. Our database is in a horrible mess AND the Rhythmyx system isn’t working correctly.
Probably not, we’re using Oracle 10g.
Still no luck finding an answer to this. I did at least finally locate the tables corresponding to my new shared field file; they weren’t named even remotely like I would have expected. But all the other old tables are still there, and tables are still misnamed.
If there isn’t a way to have Rhythmyx do this itself, is there any documentation anywhere of a way for me to clean things up by hand? I don’t want to go changing things by hand blindly and risk breaking something.
Rx will remove columns from a table when a field is removed, but content type backing tables are not removed if the type is deleted. This would have to be done manually. A content type should only be deleted if there are no instances of that type in the system any more.
Here’s how to determine the table that contains any field. Open the xml file that contains the definition for the field of interest. Find the corresponding PSXField entry (whose name attribute matches the field name.) A child node of this element is DataLocator/PSXBackEndColumn/tableAlias. Note this value(typically it IS the name of the table of interest, but you have to do an additional search to be sure.) Also in the same file is a node like PSXContainerLocator/PSXTableSet/PSXTableRef (1 or more.) Find the one of these whose alias attribute matches the previously noted alias. The name attribute of the matching element is the actual table name.
There may also be …_BAK and …_UPG tables. _BAK tables are created by the workbench in some situations when the schema is changed (e.g. by adding a new field.) _UPG are created by the installer in different situations. These can be safely removed if everything is working correctly.
Thanks for the detailed response to this. I really wish Rhythmyx cleaned up after itself - since it prevents you from deleting a content type if there are instances of it in the system, you’d think when it does allow you to delete it, it could clean up the corresponding parts in the database. Looks like I’ll have to start planning out a manual clean up.