I realized I had taken a wrong path in a site development and now have two date fields, one with single dates (but with from/to), and the other with multiple dates (also from/to). What I needed to do was migrate all dates from the single into the multiple field. I studied the database structures for the fields, the single is in the content_type table, the multiple in its own field table. I grabbed all the necessary data from the content_type table (vid, nid, field_dato_value, field_dato_value2). I then fed all this into the table for the multiple date field, adding a value for the 'delta' where necessary.

Then the problem - the multiple date values are not displaying with their respective nodes. What can I do to get the new dates properly associated with their respective nodes?

Thanks all,
kevin

Comments

sovietfunk’s picture

I have around 400 nodes to which this was meant to apply..
In the first 5-10 i looked at, the new field had not been associated properly, but now I have found many where it has indeed been successful.
But not all, and I can't quite get the logic of which nodes are successful, and which are not. Many of these nodes were imported from an old website, using the method in the handbook, but many of these have the new field, many don't.

Confused.

sovietfunk’s picture

I have understood by now that this is not a date-specific support request, it is common to all cck fields when one tries to manually insert fields. There's a huge amount of similar questions in the forum, but I haven't found anything right-to-the-point for my needs, so if anyone should pop in who has solved a similar problem, I'd be very happy to hear.

I understand this much, I think: I have to write a script to loop through all required nodes - retrieve the dates, put them in an array for the new field, append them to the node object, call node_save for each.

sovietfunk’s picture

Status: Active » Fixed

I did it!

I wrote this script and tested it for every step on my dev server before unleashing it on the staging server, pasted in a node with php input format. Sharing here for those who get the same problem. It was only made to deal with my specific fields, so one will need to doctor it. For example, i had only single dates to inject, so i expect it doesn't loop properly for multiples.
If you comment out "node_save" and enable the "print" and "print_r" lines, it's safe to run and shows if the field arrays are structured alike. When old-field and new-field look alike, give it a go. On your second viewing of the node, all nodes in the list should display "OK". I hope. In my case there were two of around 400 nodes with which it didn't work. Don't know why, yet.
No security checks, no... And i have no idea why i called the nodes $noodle. Hungry, i guess.

$result = db_query("SELECT {node}.nid FROM {node} WHERE type = 'content_type'");
while ($noodle = db_fetch_object($result)) {
    	$noodle = node_load($noodle->nid);
    	print "<pre>";
	if (!empty($noodle->target_field_name)) {
		print("<em>".$noodle->nid.": ".$noodle->title." is OK</em><br />");
                //print_r($noodle->old_field_name);
		//print_r($noodle->target_field_name);
	} else {
		print("<h2>".$noodle->nid.": ".$noodle->title." needs update!</h2><br />");
		//print_r($noodle->old_field_name);
		$tresult = db_query("SELECT * FROM `tou_drupal_content_field_arrangement_forestillinge` WHERE nid = $noodle->nid");
		$i = 0;
		while ($toodle = db_fetch_object($tresult)) {
			$new_field[$i]['value'] = $toodle->target_field_name_value;
			if ($toodle->target_field_name_value != $toodle->target_field_name_value2) { 
				$new_field[$i]['value2'] = $toodle->target_field_name_value2;
			}
			$i++;
		}
		//print_r($new_field);
		$noodle->target_field_name = $new_field;
		print("<h2>attempting to save node...</h2>");
		node_save($noodle);
		unset($new_field);
	}
	print "</pre>";
}
Anonymous’s picture

Status: Fixed » Closed (fixed)