I recently had the unfortunate experience of having to alter SELECT statements between my dev machine and testing machine since the database structure, which should be an exact match, had somehow changed between the two. Everything worked at good ole' localhost, but when I uploaded to the testing server, no query results were forthcoming.
I had created some CCK fields for a new content type and had a module using the new CCK field's value as a way to tie various articles together. (ex. All articles with "30.10.2010-05.11.2010" in this new CCK field belong to the same newsletter issue.) It turns out on my dev machine I had innocently associated the new CCK field with two content types, figuring it may be needed in two different scenarios. I never bothered doing that in my testing environment and that's where the trouble began.
It turns out that a CCK field associated with only one content type has its value saved in a table associated with that content type. (ex. content_type_name_of_content_type.field_name_of_cck_field_value). However, once you associate that CCK field with more than one content type, its values are saved in a standalone table (ex. content_field_name_of_cck_field). Clearly this is to handle general database normalisation rules so that the CCK field can be shared between multiple content types. (instead of being jammed as a column into each content_type_name_of_content_type table)
It turns out you are using an outdated browser and my site might look a bit weird for you. (images are off colour, text gets cut off, layout is wacky) This is because your browser does not implement web standards. Please consider an upgrade.