Fields that : - are used in several content types - or allow multiple values are stored in a content_field_xxx table dedicated to this field. Other fields (single and non shared) are stored in a per-content-type content_type_yyy I won't enter in the rationale for this here, but that's the pattern.
So obviously something went wrong in the migration of the definition of your content types. Hard to tell what, though, esp. if you're using a patched version of content_copy.
Also note that content_copy D5 does not support *updating* the definition of a field that already exists on the target site. Might be different in D6, but I have to say that I didn't actually test it.
The CCK issue queue would be a better place to post this, btw.
Yched
Paul Kim a ecrit le 31/10/2008 18:44:
I have a content type with several CCK fields. This site goes through the standard dev -> qa -> prod workflow, and so I have at least 3 different servers that need updates pushed on a regular basis. I'm doing this through a internal database script that I wrote, and using a patched (with the patch provided in the dbscripts module) content_copy.module for cck changes that allow updates to content types with CCK fields.
I am finding that some fields' content in my dev box is stored as a column in the content_type_xxxx (where xxxx is the content type name) table, whereas they are being stored in the content_field_yyyy (where yyyy is the CCK field name) on the QA machine. For some reason, these fields on the QA machine aren't being properly inserted into the $node variable, and they aren't being saved properly either.
What's the difference between these fields being saved in content_type_xxxx and content_field_yyyy? How do I make sure these CCK fields are stored in the same way across all three databases?
Thanks! Paul